1

I've been tasked with producing a 64-bit version of an old-style Win32 Windows application, written in C/C++ and packaged as a DLL. The 64-bit app now runs but the controls in the dialog boxes don't look the same on Win64 as Win32. The reason is that the program performs a LoadLibrary("ctl3d32.dll") and if successful, GetProcAddress() is used to collect library entry points like Ctl3dSubclassCtl(), and those entry points are then used to subclass each class of control.

However, the LoadLibrary() fails in _WIN64 because there is no 64-bit version of this DLL. This causes the controls to be rendered using the default (this is on Windows 10 -- top is Win32, bottom is Win64):

Win32 version rendered with Ctl3d32.dll

Win64 version rendered without Ctl3d32.dll

Button controls look similar enough to pass, but static controls that are used like group boxes (they look like raised pads) are drawn as plain white rectangles and edit windows don't have that inset look.

I know the right way to do this is to move the app to visual styles but for right now, it needs to look the same in Win64 and Win32. I searched in vain for a style or flag that might turn on this behavior without referencing CTL3D32.DLL.

Has anyone else encountered this problem and come up with a solution other than replicating this functionality in 64-bit GDI code or moving to Visual Styles?

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
UweBaemayr
  • 1,861
  • 1
  • 18
  • 21
  • I think you might have to write your own version of `ctl3d32.dll` if you really want the Windows 3.1 look. – Jonathan Potter Jul 22 '16 at 04:21
  • The correct solution for a unified UI in 32bit and 64bit *is* to use Visual Styles. Ctl3d is dead. Visual Styles have been around for 15 years now, use them. – Remy Lebeau Jul 22 '16 at 06:15
  • Unfortunately, this app has some unique features like a design mode and has some heavy duty WndProc plumbing and it's hard to predict how visual styles might impact end-user customized dialogs. And an attempt was made once before to move to visual styles 10 years ago and abandoned (unfortunately, can't tell why, but the conditional code is more complex than I would expect). I was really hoping I was missing some Windows API switch that that would enable the 3D drawing without CTL3D32.DLL in Win64. Oh well... – UweBaemayr Jul 22 '16 at 12:44
  • 1
    @UweBaemayr approximate it using a class background brush such as `COLOR_BTNFACE` and styles like `WS_EX_CLIENTEDGE` for the edit box? – andlabs Jul 22 '16 at 13:26
  • @andlabs - this is the approach I'm pursuing for now. The tricky bit is not overriding non-standard explicit styles set by end users. I'll take a look at MFC since it supposedly does its own 3D-look control drawing. I pretty much have to figure out what the CTL3D32.DLL library does. Too bad MS didn't open-source the CTL3D32 code. – UweBaemayr Jul 22 '16 at 16:07
  • MFC does **not** implement its own rendering code. It's a wrapper around your average native Windows controls. The visuals are no different from a Windows application written against the Windows API. – IInspectable Jul 22 '16 at 17:00
  • Compile for 32 bit. – David Heffernan Jul 23 '16 at 19:39

0 Answers0