What i am especting from a bare compiler

[Patrice Terrier]

James,

I just made a try with BCX, i can't get it to work on Windows7 64-bit (none of the GUI examples).

I did try to translate a PB file using BCX (by hand), and it reports an error when it comes to this simple declaration:
DECLARE FUNCTION SendMessage LIB "USER32.DLL" ALIAS "SendMessageA" (BYVAL hWnd AS DWORD, BYVAL dwMsg AS DWORD, BYVAL wParam AS DWORD, BYVAL lParam AS LONG) AS LONG

...

[Charles Pegge]

Patrice,
Could you try that again with quads and qwords. All handles and pointers must be 64bits wide. And all Parameters are passed in 64 bit registers or 64 bit stack locations regardless of their nominal size.

Charles

[Mike Stefanik]

I think he's saying that the parser doesn't understand how to deal with the function declaration, although you're correct that declaration is completely wrong for 64-bit Windows.

Patrice, you're not going to be able to a straight conversion like that to 64-bit code using those PowerBasic declarations. Many of them simply won't work (your program will crash) because they're written to assume that things like handles, pointers, window parameter arguments (wParam and lParam) and various return values are 32-bit when they're not on an x64 system. For example, every function that returns an LRESULT is returning a 64-bit value; if you look in the C headers for the Windows API, LRESULT is defined as 64-bits on an x64 system.

Bottom line, if you're using functions as they're declared in PowerBasic, even if the converter was able to cope with the function declaration itself your code would still break because the function parameters and return value are all the wrong sizes. If you need to go 64-bit, I think you're going to need to bite the bullet and rewrite.

Edit: I thought I'd add a link to the Windows API data types just as a point of reference. Wherever you see things typed as *_PTR (e.g.: LONG_PTR, INT_PTR, etc.) that means it's a value that is large enough to hold an address. So, for example a LONG is 32-bits on both x86 and x64 versions of Windows, but a LONG_PTR is 32-bits on x86 and 64-bits on x64. This was done primarily for those API calls where parameters were treated as integers but could be (or always were) actually values cast from pointers. Another example is a lot of the enumeration APIs in Windows allowed you to pass in a user-defined LONG or DWORD value that would then be handed back to the enumeration function; Microsoft changed all those to LONG_PTR and DWORD_PTR to allow for the programmer to pass in a pointer as well as arbitrary integer values.

[Patrice Terrier]

At this time i didn't even try to convert to 64-bit, but to 32-bit first, just to see how good BCX is to translate from PB to C, nothing else...  

...

[Mike Stefanik]

Any code converter that's going to do what you need would have to have an intrinsic understanding of the complete Windows API (and DirectX and whatever else... so you're talking about tens of thousands of functions it would need to be aware of). Even if it understood the function declaration syntax in PowerBasic, converting solely based on the existing PB declarations would result in the creation of incorrect C prototypes. In other words, the converter would need to recognize that SendMessageA was really a Windows API function, ignore the actual declaration and convert your code based on how SendMessage should be called in C/C++. Obviously, it couldn't do this with functions that it didn't recognize as part of the API and would have to convert them as-is (and you're back to the problems described above).

[Charles Pegge]

In Oxygen I am using an abstract datatype Sys which is 64 bits wide on an a x64 system and 32 bits otherwise. I hope this will help in making code cross compatible between the two systems.

Directly interpreting C headers is also possible though I am sure there a quite a few nasties out there I have yet to encounter!

Charles

[Patrice Terrier]

Mike,

BCX was written first by Kevin Diggins, that some of us may have known in the past on compuserve and/or the old PowerBASIC forum.

This is the reason why i give him some credits, he must know a little how to convert PB into C. 

[James C. Fuller]

You don't have to declare any of the winapi functions but you do have to use the correct abstract "c/c++" data types:
HWND,HINSTANCE,HDC etc. That is why most of the original bcx gui examples will not compile with g++. g++  is very strict on the naming.
A window is not s HANDLE it is a HWND for example. All the bcx gui example code was written for a very lax pelles compiler.

James

[Mike Stefanik]

It doesn't look like BCX is really an implementation of the PowerBasic syntax. For example, it looks like the equivalent of the DECLARE FUNCTION syntax is called C_DECLARE. Just browsing through the documentation, I get the impression the BCX is not really a "converter" in the sense that it's something to be used to perform a one-time conversion of BASIC source code to C. It's really more of a variant of BASIC in its own right, but instead of being its own compiler, it internally translates that BASIC code into C and passes it off to a C compiler.

In other words, BCX appears to be designed with the goal that you keep developing and maintaining your code in BASIC, and it acts more like a font-end preprocessor in the toolchain. It doesn't appear to be a tool that's really geared towards migrating you away from BASIC to C, where all subsequent development is done in C after the conversion process. It's not clear from the documentation whether BCX is 64-bit aware or not, there doesn't seem to be any explicit mention of it. I'm guessing that its not because functions like STRPTR explicitly talk about returning 32-bit pointers.

[James C. Fuller]

Here is some familiar code that will produce either 32 or 64 bit by just changing the $ONEXIT parameter.
James

Code Select Expand


$CPP
$ONEXIT "GW64.BAT $FILE$"


' **************************************************************
'    A neat little demo written by Jules Marchildon for PBDLL
'          Modified for BCX version by Kevin Diggins
' **************************************************************

GLOBAL  hDemo      AS  HWND
GLOBAL  hInstance  AS  HINSTANCE
GLOBAL  hOldFont   AS  HANDLE
GLOBAL  hMyFont    AS  HANDLE
GLOBAL  AppName$
GLOBAL  zText$



FUNCTION WINMAIN
Local Wc  AS WNDCLASS
Local Msg AS MSG

AppName$  = "BCX_Neat"
hInstance =  hInst
Wc.style           = CS_HREDRAW OR CS_VREDRAW
Wc.lpfnWndProc     = WndProc
Wc.cbClsExtra      = 0
Wc.cbWndExtra      = 0
Wc.hInstance       = hInst
Wc.hIcon           = LoadIcon   ( NULL,IDI_APPLICATION )
Wc.hCursor         = LoadCursor    ( NULL, IDC_ARROW )
Wc.hbrBackground   = CreateSolidBrush(RGB(255,0,0))
Wc.lpszMenuName    = NULL
Wc.lpszClassName   = AppName$
RegisterClass(&Wc)

hDemo = CreateWindow ( AppName$, "BCX", WS_CAPTION OR WS_SYSMENU, _
0, 0, 400, 200, HWND_DESKTOP, NULL, hInst, NULL)

Center (hDemo)
Show   (hDemo)

While GetMessage (&Msg,NULL,0,0)
  TranslateMessage  (&Msg)
  DispatchMessage   (&Msg)
Wend

Function = Msg.wParam
End Function






FUNCTION WndProc ()

LOCAL  hRgn1  AS  HRGN
LOCAL  hRgn2  AS  HRGN
LOCAL  rc     AS  RECT
LOCAL  hDC    AS  HDC


SELECT CASE Msg

  CASE WM_CREATE
  hDC= GetDC(hWnd)
  zText$ = "BCX!"
  hMyFont = CreateFont (200,0,0,0,1000,FALSE,FALSE,FALSE,ANSI_CHARSET, _
  OUT_CHARACTER_PRECIS,CLIP_DEFAULT_PRECIS,      _
  PROOF_QUALITY,FIXED_PITCH,"Courier New" )

  hOldFont = SelectObject(hDC,hMyFont)
  CALL BeginPath(hDC)
  CALL TextOut (hDC, 0, 0, zText$, LEN(zText$))
  CALL EndPath (hDC)
  hRgn1 = PathToRegion ( hDC )
  CALL GetRgnBox ( hRgn1, &rc )
  hRgn2 = CreateRectRgnIndirect( &rc )
  CALL CombineRgn(hRgn2, hRgn2, hRgn1, RGN_XOR)   ' <<<-- Try RGN_AND
  CALL DeleteObject(hRgn1)
  CALL ReleaseDC(hWnd,hDC)
  CALL SetWindowRgn(hWnd, hRgn2, 1)
  CALL SelectObject(hDC,hOldFont)
  EXIT FUNCTION


  CASE WM_LBUTTONDOWN
  CALL ReleaseCapture
  CALL SendMessage (hDemo,WM_NCLBUTTONDOWN,HTCAPTION,0)
  EXIT FUNCTION


  CASE WM_RBUTTONUP
  SendMessage (hWnd,WM_DESTROY,wParam,lParam)
  EXIT FUNCTION


  CASE WM_DESTROY
  PostQuitMessage (0)
  EXIT FUNCTION

END SELECT
FUNCTION = DefWindowProc (hWnd,Msg,wParam,lParam)
END FUNCTION



[James C. Fuller]

Mike,
  The 32/64 is NEW. like less than a week and came about by me finding the new MinGw32/64 cross compilers. It's a real new learning experience for me bcx,c++,g++ specific, 32/64.. wxWidgets ... I'm tired....
James

[Mike Stefanik]

The 32/64 is NEW. like less than a week and came about by me finding the new MinGw32/64 cross compilers. It's a real new learning experience for me bcx,c++,g++ specific, 32/64.. wxWidgets ... I'm tired....

Ah, that would explain why it's not mentioned. Am I right though that BCX is really designed to function as a language you develop in, rather than just a one-shot conversion tool? That's the impression that I got when I was reading through the docs online. That being the case, it sounds like an option for Patrice would be to just focus on modifying his PowerBasic source code to use the BCX syntax and he could stick with keeping his code largely in BASIC rather than a wholesale conversion to C/C++.

[James C. Fuller]

The 32/64 is NEW. like less than a week and came about by me finding the new MinGw32/64 cross compilers. It's a real new learning experience for me bcx,c++,g++ specific, 32/64.. wxWidgets ... I'm tired....

Ah, that would explain why it's not mentioned. Am I right though that BCX is really designed to function as a language you develop in, rather than just a one-shot conversion tool? That's the impression that I got when I was reading through the docs online. That being the case, it sounds like an option for Patrice would be to just focus on modifying his PowerBasic source code to use the BCX syntax and he could stick with keeping his code largely in BASIC rather than a wholesale conversion to C/C++.

You are correct. Bcx is a programming language whose backend is c/c++ code.

Maybe anymore discussion should move to the Bcx board: http://www.basic-compiler.com/forum/

James

[Patrice Terrier]

James

Maybe anymore discussion should move to the Bcx board

We can also speak of BCX here, because this is a "discussion" thread, and the information would benefit to all those who are concerned.

...

[Patrice Terrier]

Mike,

I have upgraded to VISUAL STUDIO 2010 Pro 

More than three years that i haven't written a single line of C# code, looks like i have forgotten everything 

...