gcc bounce2 issue

[Robert]

The link below is also very relevant
https://devblogs.microsoft.com/oldnewthing/20070410-00/?p=27313

On my Windows 11 x64 machine, this code

Code Select Expand

$DEFINE NTDDI_VERSION 0x0A000007

PRINT "NTDDI_VERSION  : " , HEX$(NTDDI_VERSION )

PRINT "WINVER         : " , HEX$(WINVER)

PRINT "_WIN32_WINNT   : " , HEX$(_WIN32_WINNT)

PRINT "_WIN32_IE      : " , HEX$(_WIN32_IE)

compiled with  MSVC, Pelles C, Nuwen, LLVM, and LLVM-MinGW, when run, prints

Code Select Expand

NTDDI_VERSION  : A000007
WINVER         : A00
_WIN32_WINNT   : A00
_WIN32_IE      : A00

Changing the value of the NTDDI_VERSION define, this code

Code Select Expand

$DEFINE NTDDI_VERSION 0x06030000

PRINT "NTDDI_VERSION  : " , HEX$(NTDDI_VERSION )

PRINT "WINVER         : " , HEX$(WINVER)

PRINT "_WIN32_WINNT   : " , HEX$(_WIN32_WINNT)

PRINT "_WIN32_IE      : " , HEX$(_WIN32_IE)

compiled with  MSVC, Pelles C, Nuwen, and LLVM, when run, prints

Code Select Expand

NTDDI_VERSION  : 6030000
WINVER         : A00
_WIN32_WINNT   : A00
_WIN32_IE      : A00


but compiled with LLVM-MinGW, when run, prints

Code Select Expand

NTDDI_VERSION  : 6030000
WINVER         : 601
_WIN32_WINNT   : 601
_WIN32_IE      : 800

[Robert]

Hi MrBCX:

in https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

It is stated

If you define NTDDI_VERSION, you must also define _WIN32_WINNT.

How to test if define _WIN32_WINNT is needed or, as Raymond Chen wrote, not needed?

How?  I'll show you how:

Translate and compile these 2 lines then run:

PRINT "NTDDI_VERSION: " , HEX$(NTDDI_VERSION )

PRINT  "_WIN32_WINNT : " , HEX$(_WIN32_WINNT)


OUTPUT FROM VARIOUS COMPILERS:

Pelles
NTDDI_VERSION: A000000
_WIN32_WINNT : A00

MSVC
NTDDI_VERSION: A000000
_WIN32_WINNT : A00

Mingw
NTDDI_VERSION: A000000
_WIN32_WINNT : 502

Clang
NTDDI_VERSION: A000000
_WIN32_WINNT : 603

LccWin32
Error a.c: 223  undeclared identifier 'NTDDI_VERSION'
Error a.c: 224  undeclared identifier '_WIN32_WINNT'

Excellent ! Thank you.

[MrBcx]

Hi MrBCX:

in https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

It is stated

If you define NTDDI_VERSION, you must also define _WIN32_WINNT.

How to test if define _WIN32_WINNT is needed or, as Raymond Chen wrote, not needed?

How?  I'll show you how:

Translate and compile these 2 lines then run:

PRINT "NTDDI_VERSION: " , HEX$(NTDDI_VERSION )

PRINT  "_WIN32_WINNT : " , HEX$(_WIN32_WINNT)


OUTPUT FROM VARIOUS COMPILERS:

Pelles
NTDDI_VERSION: A000000
_WIN32_WINNT : A00

MSVC
NTDDI_VERSION: A000000
_WIN32_WINNT : A00

Mingw
NTDDI_VERSION: A000000
_WIN32_WINNT : 502

Clang
NTDDI_VERSION: A000000
_WIN32_WINNT : 603

LccWin32
Error a.c: 223  undeclared identifier 'NTDDI_VERSION'
Error a.c: 224  undeclared identifier '_WIN32_WINNT'

[Robert]

FYI -- According to Raymond Chen, NTDDI_VERSION is the only OS target symbol that we need to define:

I've replaced these in my batch files:

WINVER
WIN32_WINNT
_WIN32_IE

with: 

NTDDI_VERSION = 0x0A000000

I'm still testing but, so far, the compiles and resulting exe's seems to be working normally.

ref:
https://devblogs.microsoft.com/oldnewthing/20070411-00/?p=27283

https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

Hi MrBCX:

in https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

It is stated

If you define NTDDI_VERSION, you must also define _WIN32_WINNT.

How to test if define _WIN32_WINNT is needed or, as Raymond Chen wrote, not needed?

[MrBcx]

FYI -- According to Raymond Chen, NTDDI_VERSION is the only OS target symbol that we need to define:

I've replaced these in my batch files:

WINVER
WIN32_WINNT
_WIN32_IE

with: 

NTDDI_VERSION = 0x0A000000

I'm still testing but, so far, the compiles and resulting exe's seems to be working normally.

ref:
https://devblogs.microsoft.com/oldnewthing/20070411-00/?p=27283

https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

[jcfuller]

Robert,
  I updated my WIN_VER , which I use on the compile line to the same code as VC.
SET WIN_VER=-DWINVER=0x0A00 -D_WIN32_WINNT=0x0A00

Same results.

James

[Robert]

Kevin,
  Attached is your version of the GUi Demo Bounce along with an exe compiled with TDM-GCC
I attached the source because I may have altered it ??
bc 7.7.2 translates ,IOA does a fix for the VSC,TDM-GCC,NUWEN GCC,CLANG compliers. They all compile and the app runs fine BUT
the gcc apps window is larger than the  windows display area.
I am not describing this well. Run the exe or compile it yourself with nuwen or tdm gcc.
VC and CLANG and Pelles are fine.

James

Hi James:

Have you got a different value for WIN32_WINNT in your gcc batch file than in the others?

[MrBcx]

Maybe add it to BCX?
James

I'm very familiar with that SUB and have used it before -- in fact, I keep a BED macro for it.

I would support adding it to BCX, along with another useful macro that I sometimes use:

SUB BCX_RESIZE (hwnd AS HWND, cx, cy)
  SetWindowPos (hwnd,NULL, 0, 0, cx, cy, SWP_NOMOVE|SWP_NOREPOSITION|SWP_NOZORDER|SWP_FRAMECHANGED)
END SUB

[jcfuller]

Kevin,
  When using José's CWindow I always use  the setclientsize method instead of a window size so I know exactly what I am working with.
Maybe add it to BCX?
James

Code Select Expand


' Adjusts the bounding rectangle of a window based on the desired size of the client area.
' Parameters:
' - hwnd = The window handle.
' - nWidth and nHeight = The desired size of the client area.
' - rxRatio and ryRatio = Scaling ratios.
'------------------------------------------------------------------------------
Sub AfxSetWindowClientSize(hwnd As HWND,nWidth As Long,nHeight As Long,rxRatio = 1 As Single,ryRatio = 1 As Single)
    Dim As RECT rc,rcTemp
   ' // Convert the client rectangle to a window rectangle.
   ' // The AdjustWindowRectEx function cannot take menu wrapping into account
   ' // because it doesn't know which menu we are using.
    SetRect(&rc,0,0,nWidth * rxRatio,nHeight * ryRatio)
    Raw As HANDLE hMenu = GetMenu(hwnd)
    Raw As DWORD dwStyle = GetWindowLongPtr(hwnd, GWL_STYLE)
    AdjustWindowRectEx(&rc, dwStyle, (hMenu <> NULL), GetWindowLongPtr(hwnd, GWL_EXSTYLE))
   ' // If there is a menu, we need to check how much wrapping occurs when we set
   ' // the window to the width specified by AdjustWindowRectEX and an infinite
   ' // amount of height. An infinite height allows us to see every single menu wrap.
    If hMenu <> NULL Then
        rcTemp = rc
        rcTemp.bottom = 0x7FFF   ' // "Infinite" height
        SendMessage(hwnd, WM_NCCALCSIZE, 0, (LPARAM) &rcTemp)
        ' // Adjust our previous calculation to compensate for menu wrapping.
        rc.bottom = rc.bottom + rcTemp.top
    EndIf
   ' // The AdjustWindowRectEx function does not take the WS_VSCROLL or WS_HSCROLL
   ' // styles into account. To account for the scroll bars, we need to call the
   ' // GetSystemMetrics function with SM_CXVSCROLL or SM_CYHSCROLL.
    If (dwStyle BAND WS_HSCROLL) = WS_HSCROLL Then
        rc.bottom = rc.bottom + GetSystemMetrics(SM_CYHSCROLL)
    End If
    If (dwStyle BAND WS_VSCROLL) = WS_VSCROLL THEN
        rc.right = rc.right + GetSystemMetrics(SM_CXVSCROLL)
    End If
    Raw As Long cx  = rc.right - rc.left,cy = rc.bottom - rc.top

    SetWindowPos(hwnd, NULL, 0, 0, cx, cy, SWP_NOZORDER BOR SWP_NOMOVE BOR SWP_NOACTIVATE)
   
End Sub


[MrBcx]

Why the difference?

I never said it was a BCX thing ... I said it was a Windows thing.

You are taxing my memory now but I seem to recall reading in Petzold about a
hundred years ago that sizeable / non-sizable forms have different border thicknesses
and which I inferred affected the client area real estate in this demo.  It's not a problem
that I've ever dealt with before.

I may have dreamed it or I may be completely wrong about this.

The bigger lesson ( for you ) is that simply pasting your MODSTYLE macro into someone
else's code might not work out the way you think.

[jcfuller]

Kevin,
  This is NOT a BCX issue.
  I don't NEED MODSTYLE. I thought it would be a bit easier then using
     Form1 = BCX_FORM("Bounce!", 0, 0, 300, 40,WS_MINIMIZEBOX | WS_CAPTION | WS_POPUP | WS_SYSMENU)

With my tests using the Form1 = from above (NO MODSTYLE)
In WM_CREATE
VC,Pelles,Clang
  Anim_Width    592
  Anmin_Height   65
Gcc
  Anim_Width    602
  Anmin_Height   75


Why should you have to  add 20 & 10 when compiling with gcc ?
    Anim_Width  = rcClient.right  + 20
    Anim_Height = rcClient.bottom + 10

Why the difference?
James

[MrBcx]

Kevin,
  I know this is only a demo but there is no need for a max button or sizing so I removed them.  It allows Suzy User to make a mess of it when running the app.
  The main point here is it fails for the gcc versions. Visual "C" and Clang "C" using IOT works the same as Pelles.

James

You have a strange obsession with Suzy User.

More importantly, things have consequences, especially in Windows.  If you insist on using the MODSTYLE
statement, then you need to be aware that that changes the client area metrics which the demo relies upon. 
On my system, changing this
   
Anim_Width  = rcClient.right   
Anim_Height = rcClient.bottom

to this

Anim_Width  = rcClient.right  + 20
Anim_Height = rcClient.bottom +10

corrects the ball is going too low problem  which is caused by your MODSTYLE statement.

The attached zip contains my updated ball image, your MODSTYLE statement, and my _Build_GCC.bat
commands.  A copy of rc.exe should be in the \BCX\BIN folder.   You can use any resource compiler that
you want or else simply use your existing Bounce.res or the one in the zip file. 

I used your most recent IOA app, gcc to compile, and Mike Henning's LinkRes2Exe app to build the exe.

VirusTotal reports 2 detections out of 62 .

[jcfuller]

Kevin,
  I know this is only a demo but there is no need for a max button or sizing so I removed them.  It allows Suzy User to make a mess of it when running the app.
  The main point here is it fails for the gcc versions. Visual "C" and Clang "C" using IOT works the same as Pelles.

James

[MrBcx]

JC -- You definitely altered it.

When  I remove all of this stuff:

'$ONEXIT "ASTYLE -pn $FILE$.c"
''$ONEXIT "VSC.BAT $FILE$ -m64 gui"
''$ONEXIT "NUWENGCC.BAT $FILE$ -m64 gui"
'$ONEXIT "TDMGCC.BAT $FILE$ -m64 gui"
''$ONEXIT "CLANGC.BAT $FILE$ -m64 gui"
''$ONEXIT "PEL.BAT $FILE$ -m64 gui"

and most importantly, remove this from your version:

MODSTYLE(Form1,0,WS_SIZEBOX|WS_MAXIMIZEBOX)   'no size or max box

all is well when I compile with Lcc,  Pelles, Mingw, and MSVC using my batch files.

[ADDED]  When I run it thru IOA and gcc, also well.

[jcfuller]

Kevin,
  Attached is your version of the GUi Demo Bounce along with an exe compiled with TDM-GCC
I attached the source because I may have altered it ??
bc 7.7.2 translates ,IOA does a fix for the VSC,TDM-GCC,NUWEN GCC,CLANG compliers. They all compile and the app runs fine BUT
the gcc apps window is larger than the  windows display area.
I am not describing this well. Run the exe or compile it yourself with nuwen or tdm gcc.
VC and CLANG and Pelles are fine.

James