Guidelines for Contributing to QB64

[mnrvovrfc]

I disagree with point #6.

Assembly should be allowed in my opinion - some other BASICs have it.

Ask the head developer of Purebasic how he goes about doing things so the messy business is translated into one of three operating systems and at least two architectures (x64_64 and ARM). Reading the "gcc" manual*, in the chapter about extensions to "ANSI C" reveals some mind-boggling things that were done for the sake of portability.

* @a740g provided a link above with information...

Learned from Spriggsy : might have to do "DECLARE CUSTOMTYPE LIBRARY" if "DECLARE LIBRARY" doesn't work.

I have code for Turbo Pascal which doesn't run on my outdated copy of 32-bit Free Pascal, before we start talking about assembly blocks supported by that programming language which are all over the contributions of the great PC MAGAZINE book written by N.J.Rubenking. "Oh but Purebasic looks like Pascal then like that, which is what I want," well, not on freeware anytime soon, not toward programmers doing this as hobby and not being paid for it, and with less than 5% of people downloading the product donating for it regardless of the orange-button company.

To make a long story short: I don't want to see any "ASM... END ASM" blocks in QB64(PE) code. Sorry. I like the current system of including "dot-H" files for people like me who are afraid of C/C++ and then, "What assembly? It's too hard!"

About Galleon (maybe) having used M$ BASIC PDS v7.1, it was a start for QB64, or it might not have started at all. This is despite the fact there was a lot of emphasis on compatibility with QBasic (ie. the interpreter packaged with MS-DOS 5+) and not as much with any other BASIC language product.