3

I have just ported a dialog based MFC program from Visual Studio 6 to to Visual Studio 2013. There were no major issues and the program runs perfectly once compiled under VS 2013.

The only visible difference is the thickness of the dialog's borders (see screen shots below made under Windows 7).

enter image description here

More facts:

  • It's not a manifest issue, both manifests in the old and new versions are strictly the same.
  • The .rc hasn't been messed up during the conversion of the project by VS2012. If I compile the converted project again with VS6 I get thin borders.
  • I can reproduce the issue with a freshly wizard generated program in Visual Studio 6.
  • A message box shown with AfxMessageBox also has a thin border when compiled with VS6 and a thick border when compiled with VS2013.
Jabberwocky
  • 48,281
  • 17
  • 65
  • 115
  • In newer versions of Windows, the system parameter for the border thickness was broken into two parts. The upward compatibility of this change was poorly considered on Microsoft's part. It's likely that VS2013 compensates properly for the change while VS6 does not. – Mark Ransom Jan 13 '16 at 17:07
  • @MarkRansom could you be more specific about that border thinkness thing you were writing about? Even a message box displayed with a raw `::MessageBox` exhibits this difference in behaviour; it's like there was some application wide setting being applied somehow- There is [another SO question](http://stackoverflow.com/questions/34768621/win32-control-distortion-in-visual-studio-2013) dealing with a similar problem. – Jabberwocky Jan 13 '16 at 18:13
  • 2
    The parameter I'm thinking of is `SM_CXPADDEDBORDER`, which didn't exist when VS6 came out. I don't have any more information than that right now, sorry - if I did I'd leave an answer. If it helps, I think the VS6 borders are too thin and the VS2013 borders are correct. – Mark Ransom Jan 13 '16 at 19:42
  • @MarkRansom just googled "SM_CXPADDEDBORDER" and the first results show many "problem"s and "incorrect"s, looks as if this is the right lead. Thanks. – Jabberwocky Jan 13 '16 at 19:46
  • 1
    @MichaelWalz I remember we have experienced similar issue and that time it was related with subsystem flags of PE header or like that. Would you mind to drop an output of dumpbin /A of both binaries (especially "operating system version" and "subsystem version" value)? If they differ, that's the reason, I'll write more detailed answer. – Artem Razin Jan 14 '16 at 09:28
  • @ArtemRazin you are right, with subsystem version 6.0 I get the the thick borders and with subsystem 4.0 I get the thin borders. If you make this an answer I'll accept it and yo'll get an upvote from me and my work mates. – Jabberwocky Jan 14 '16 at 09:50
  • 1
    @MichaelWalz I think it is the same issue which am discussing here :http://stackoverflow.com/questions/34768621/control-displayed-with-an-offset-in-visual-studio-2013, Please let me know if you have solution of this – WENzER Jan 14 '16 at 11:52
  • 2
    If your application has a subsystem version less than 6.0 (as set by the linker), then the operating system will lie to it (for backwards compatibility reasons, since `SM_CXPADDEDBORDER` was added to Vista) about the size of the window's border padding. If the subsystem version is >= 6.0, then you get the real information. – Cody Gray - on strike Jan 14 '16 at 12:48

1 Answers1

2

I have experienced similar issue and it was related with subsystem flag of PE header.

I needed to debug Windows a bit to find the reason: the function win32k!_GetWindowBorders checks that PE flag against 6.0 (probably to support new flag SM_CXPADDEDBORDER).

See also:

Roman R.
  • 68,205
  • 6
  • 94
  • 158
Artem Razin
  • 1,234
  • 8
  • 22