For now the Full bc9 package can be downloaded from:
https://sites.google.com/site/jcfbcx2/home/bcx9

For this version I strongly recommend the MinGWTDM64 compiler suite.
For 64bit systems:http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm64-gcc-4.7.1-3.exe/downlad

For 32bit systems:http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.7.1-2.exe/download 

See the bc9 ReadMe.txt about setting the paths in RadAsm3.


  The conversion of the Patrice test code went better than I had anticipated but I doubt it is working correctly.

Here are the main points.

bc9 using MinGW gcc is ansi/iso "c" only. No optional parameters as in Lcc and PellesC.
bc9 can create code for MinGW g++,Lcc,PellesC,BC++ 5.5,c++ VS2010 but from what I understand what Patrice wanted
now is a conversion from PowerBASIC and for that I would recommend MinGW gcc. VS2010 supposedly can compile
to 32/64 from "c" code but I am not that familiar. I do supply batch files with the package you can test.

Note the Bcx help file is extensive and very well written and will probably give you even better insight
into the differences than I list here.

Changes from the help file for bc9 and gcc.
  No optional parameters. Include the default values when using.
  chr$(val) takes only one parameter. If you need more use The vchar$() function.




Differences I found and remember :)

Arrays are always zero based and use brackets instead of parentheses.

QUAD = LONGLONG (bcx syntax) or long long (c syntax)

default function passing is BYVAL. Bc9 has no problem with the BYVAL or BYREF but when passing
to a function that needs BYREF pass the variable by prefixing an ampersand. x = myfunc(&myvar)

% appears to be no problem within a windows call back: CASE %WM_COMMAND but I would refrain from using them
% cannot be used to declare and assign a constant.
For
%PixelFormatUndefined   = 0 
Use
CONST PixelFormatUndefined   = 0


All STRINGs are ASCIIZ * 2048 by default.


You should add BYREF to function parameters so correct code is generated
SUB FLY_Timer(dwTime AS DWORD, dwProc AS DWORD, BYVAL RW AS LONG)
  to
SUB FLY_Timer(BYREF dwTime AS DWORD, BYREF dwProc AS DWORD, BYVAL RW AS LONG)

also note when you call a function with a BYREF you need to prepend the apersand to the var name
CALL FLY_Timer(&dwT, &dwProc, 0)
If you compile with full warnings it will flag this. You just have to recognize this as an error.

Don't use BYREF for passing STRING's



See the help file for dimentioning strings larger than 2048.

The keyword STRING can only be used with "c".
If you plan on using c++ you probably should convert to c++ string.

One nice point is the declares for dll functions seem to be the same.

No need for Alias in exported functions. 

Show stoppers?
    No direct subsitute for DIR$. See help file for FINDFIRST$/FINDNEXT$
    I plan to add a DIR$ function to bc9

    No CALL DWORD. See the help file on FUNCTION and SUB Pointers.


I am not sure on 32 to 64 and the use of longs in Pb code?
Same probably goes for DWORD but you'll have to do some research on that.

I think the size and complexity of the source makes it a little hard to check.

I use DiffMerge from www.sourcegear.com to compare the original source to the converted one.



James


