As regards the prolific use of PtrToUlong deprecated in the VS2017-or-later-compliant environment, should we keep the repository unedited?

A while ago I learnt (hard way) that one should use a standard-compliant reinterpret_cast<LONG_PTR>(pointer) instead of a proprietary PtrToUlong function, which use is prolific among Windows classic samples projects. Since then, I've happened to advise colleagues and students on that matter, but yesterday myself bumped into the not-so-obvious consequence of this bug. If built with VS2022, the DWriteHelloWorld.exe of an eponymous project does not even arrive at showing the main window, with a seemingly cryptic access violation exception in the _SCRT_STARTUP_WWINMAIN-branch routine that the debugger reveals as happening in exe_common.inl, line 123. Only examination of a call stack window indicates that the culprit is a TabWindow::OnResize(..) call. When created, TabWindow fails to save its USERDATA with a ::SetWindowLongPtrW(hwnd, GWLP_USERDATA, PtrToUlong(pTabWindow)) call, and consequently fails to initialize pTabWindow when processing the WM_SIZE message.

I wonder if we should edit the Windows classic samples repository, or should we keep PtrToUlong in its code as a relic of retro-computing and arguably useful debugging exercise for students?

Start by reproducing the DWriteHelloWorld failure under VS2022 and inspect TabWindow::OnResize, especially the SetWindowLongPtrW call mentioned in the report. Then search the Windows classic samples repository for other PtrToUlong uses. Done means the affected sample reaches its main window and the repository-wide treatment of remaining uses is decided and documented.