Hacker News Reader

Comment by jordand | Hacker News Reader

The one big challenge I've had with big legacy Win32/C++ codebases is migrating it fully from 32bit to 64bit. Loads of know-how and docs for complex GUI controls and structs are lost to time, or really fragmented. Other than that, yeah it really does all just work once you're past that.

View on HN

Well it's still a 32 bit program so I guess that helps. Would probably require some porting to make it 64 bit native, but as long as you use the WPARAM, INT_PTR typed and what not correctly it 'should just work'.

Yeah that's the bulk of the work for migrating small Win32 apps. Things escalate when someone has built their own dynamic GUI framework over Win32, used a range of GUI controls, and then built event-driven apps on top of that, it's a lot lol

I went through that a few years ago and it actually went pretty smoothly. There were a few UINT_PTR or DWORD_PTR changes I had to get used to and a couple of string glitches (we mostly used the _T() macro for strings and already used the _t variants of string functions in the original code, so that helped).

The biggest problems were DAO (database) and a few COM controls that were not available in x64.

Having to use macros for literal strings in your code is just incredibly stupid of Microsoft and/or C++.

How do Linux and Java do it, when you want to compile your program in both 16-bit char and 8-bit char mode? Oh that's right, you don't.

You can pick one or the otherfor Windows too, so don't ask me why it's done that way. It was originally so you could compile for both the new hotness Unicode, and the old compatible ASCII.

Partly because Microsoft resisted UTF-8 forever, and so using the ANSI/multibyte strings didn't therefore give you modern functionality. Why they didn't implement Unicode for Win95, I'm just not sure. If they had, the only reason to compile an ANSI version would have been to target Win32S (Windows 3.11).

Or, they could have implemented a UTF-8 code page for Win32 as soon as it was available and then most software could just use byte strings.

In 32-bit windows, you used to be able to see if a pointer was valid or not by seeing if it pointed to the last 2GB of address space. If it did, it was pointing to Kernel memory that was not valid for user mode code.

But then Large Address Aware (4GB limit) changes everything, and you can't do that anymore. In order for a program to be Large Address Aware, you need to not try to do things like check high bits of pointers, then every single library and DLL you use also needs to do the same.

That sounds like the same ugly hack that caused programs not to be “32 bit clean” back in the day for Macs

One difference is that the Mac OS itself was not initially 32-bit clean, with the top byte being used by the Memory Manager.

Ah yes, these 68000 pointers have a spare 8 bits for me to use! Because nothing will ever need more than 16 MB of memory. Sigh.

It's all good if you have 128kb ram but they should have had a plan to escape it from day one.

This is how pointer authentication codes work on Arm64.

Doesn't WINE have pretty decent documentation by now from all the reverse engineering?

Wine cannot even install office 2014. It's not really as food as some claim sadly.

Lutris can up to 2016.

Win32 programming has been reduced to a small niche now. Even 20+ year old Win32 books don't cover things in-depth (or practical use cases) let alone the 32bit->64bit migration

Reply on news.ycombinator.com