BCET - What's it good for?NEW 07/23/2004: This page needs more work, but documentation is not really my strong point. BCET is useful to create win-32 console mode or GUI mode programs. The original intention was to recompile working programs to console mode, either to get around memory limitations, or to get long file name support, or to move away from DOS. There is only limited support for calling win-32 API's. There is now some additional support for API calls. DOS programs that make use of external libraries (I know of QuickPAK, and there are others) will have to be modified as there is no ability to call the 16-bit DOS libraries. The only portions of the compiler that are really known to work, are those actually used by the compiler itself. It does compile itself correctly, and that result compiles correctly . . . And the samples compile and run correctly. At the moment, BCET expects that the source file did run correctly in QB or PDS or QBasic. Checking for the correct operands to functions and other such like didn't make it into BCET due to the limited development environment. As BCET becomes more stable, I expect to add quite a lot of additional checking. There has been a fair amount of testing beyond just the compiler itself, however it is not really all that extensive. A number of Basic statements aren't supported, for a number or reasons: They have little or no meaning in a protected mode environment (IN, OUT, PEEK, POKE ...). I have no idea how to make them work (All GRAPHICS Statements, all 'ON Event' Statements) There is support for the 'ON [LOCAL] ERROR GOTO' statement, but none yet for the RESUME NEXT form. RESUME NEXT requires a table of the address of every statement in the program, a great space waster. I don't think they should work (TIME and DATE statements - use the windows clock) The result won't be compatible with MS Basic (BLOAD and BSAVE) There is no resonable way for the compiler to handle it (DEF fn - use a real function) I don't even want to think about trying to support it (ISAM) There is no good or easy way for the runtine code to handle something (PLAY, IOCTL in any form, KYBD: SCRN: COMn: LPTn: CONS: PIPE:) |