O2 vs. FB

[JRS]

I would like to start an open discussion about the benefits, limitations and resources behind both OxygenBasic and FreeBASIC. I'm hoping for a frank discussion on what is the best use of a contributor's time if their interests were a BASIC compiler. Would time be better spent updating FreeBASIC from its DOS/Win32 roots or help the O2 project along with documentation and organizing the many examples so others can use it? Below is my +/- list for both compilers.

FreeBASIC

• A mature BASIC compiler with over 10 year in the making with a once large user base when QB was king and a migration path to Windows.
• The original author (Victor) has moved on and is only monitoring the project. His last effort was a C emitter that generates human unreadable C source code.
• Even though a Linux port is distributed, it's 32 bit only and very buggy on that platform. Trying to get it to run on 64 bit Linux (with 32 bit libraries) is a waste of time.
• FB uses custom include files that always seem to be out of date or non-existent. Maintaining them is like pulling teeth.
• The forum is run like a club for QB programmers that are grumpy old farts that are rude and act like thugs. There is no sense of a future lingering.
• Just like Rapid-Q, I wish somebody would just shoot it and put it out of it's misery.

OxygenBasic

• O2 is a Charles Pegge production and few can take credit for moving this outstanding open source project along.
• Like with any new language (BASIC or not) good documentation or a broad set of example code is crucial to attract new interest to the project. I feel this is one of the biggest problems with O2 and the easiest to solve.
• O2 is the only PE and JIT BASIC compiler out there. It is known to compile both 32 and 64 Windows code.
• Charles is actively developing a C emitter which is feeding his C BASIC open source project.
• With O2, a bugs life is short followed by a fix before you can come up with a workaround.
• Charles's OxygenBasic has helped both thinBASIC and ScriptBasic in a BIG way giving the idea of using interpreters a second look.

Your thoughts?

[Mike Lobanovsky]

John,

I'm the newest member here and it may seem not very becoming to me to be the first one to respond. But I can't help it because in my opinion there are too many questionable starting points to launch such a discussion however timely or pressing it might look to somebody.

1. I'm not sure the topic is formulated correctly. IMO there should be no versus'es sought in such pairs as PowerBASIC and thinBasic, FreeBasic and OxygenBasic, or even Emergence Basic and AurelBasic, for all I care. The former is a parent to the latter; a child depends on its parent at least in its green years and there's no reason to expect a language developer's unfaithfullness to his preferred pragramming tool that has already brought about so much joy and satisfaction to him.

So long as Charles continues to use FreeBasic to develop OxygenBasic to our common satisfaction, both Charles and his peers are expected to remain loyal to FreeBasic no matter what others say, and I find it only natural.

Provisions are being made by Charles actively to move on to another more promising development platform in due time. As soon as it happens, we might discuss its pluses and minuses but even then, noone should expect Charles to become unloyal or unthankful to the language that helped get his own project up and running.

2. Quotations from a man that can't be sure where to start with a BASIC (?) can't be taken seriously as a ground for initiating an epoch-making discussion among BASIC language developers. I think I'm already standing a little farther ahead than that along the line of my programmatic hominization. Talking about "noise" in an Intel chip is pure nonsense pretty much as is his refusal to buy a 64-bit Intel chip in an era when there are already generations of young people that have never seen a fossil 32-bit Intel chip with their own eyes.

3. FreeBasic is a free-for-all product and as long as there is at least one dedicated someone remaining that's happy with what he has, the language has the right to live and in the eyes of that someone the rest of the world may go to hell. That's the beauty and the tragedy of all public open-source projects in the world. Irresponsibility is their epitaph. And do not say you weren't warned in time; you were, just re-read their licenses.

4. Header files is a curse unbegun of 99.99 per cent of all existing languages. But who said I don't know what I'm calling in my program and how I should do it? One very wise FBSL user once said: "How much do we want our data to be refined for us?". I shall be grateful to this wisard (he's my elder) to the day I die. Now how about a pinch of FBSL for a change? It doesn't use function declarations or header files at all and has been around doing that for a dozen years already.

[JRS]

Thanks for your feedback Mike. My goal with this thread to not to reinforce loyalties. If I were a programmer looking for an open source BASIC compiler and an active community, what would be a better use of my time? The real question is if FreeBASIC is too old to save or is QxygenBasic too open ended to contain? I view O2 much the same way I view gcc. It has a lot of ways of using it but requires additional libraries and a framework to be usable.

[Mike Lobanovsky]

Writing documentation is a hateful yoke for any creative programmer. Even simple annotation of own code is regarded as unproductive and unpardonnable waste of time. I'm no exception to this rule myself.

I used to know only one person in my life who broke the rule and that was Mr.Robert Wishlaw of BCX. BCX Help is still the only BASIC reference manual I consider spotless and irreproachable even though many other aspects of BCX community left much to be desired when I quit about a decade ago. Mr.Wishlaw was a perfect BCX annalist and book keeper and he himself remained a very talented programmer at that.

A programming language help writer must himself be a guru in the language he annotates. He must also be a native and learned English speaker. Public-access wikis are a nightmare.

[JRS]

I think Peter Verhas takes the prize for authors that have documented their own work. Not only did he create the user docs but a complete set of developer docs for embedding and extending the BASIC. English isn't Peter's native language (one of a dozen) and I'm still amazed how well it turned out. I need to give it a freshening up for the SB 2.2 release.

[JRS]

FreeBASIC is Born

FreeBASIC was first programmed in VB-DOS, with the goal of compiling itself. Because of this, both its syntax and runtime library are designed to emulate
QB's syntax and runtime as far as it is practical in a 32-bit Windows environment. For the most part, the two dialects are extremely similar, and most code can be ported with little or no modification, though in some cases routines reliant on 16-bit DOS must be rewritten. The resulting compiler shares a greater similarity to QB than any compiler on the market, including Visual Basic.

Because of its open source, its well-written code and its similarity to QB, FreeBASIC has become popular among the "QB Community" and its boundaries continue to grow as it receives more attention and gathers more features that promise to move BASIC into the future.

Back to the FreeBASIC discussion. Is porting user applications to C in a obfuscated format still FreeBASIC? What makes this any different from BCX or BaCon? Is there any plans to port FreeBASIC (written in itself) to Linux native or is that an impossible dream? Just like PowerBASIC that has patched its way along to stay relevant, is a rewrite to do it right worth the effort? Doesn't it make sense to support a BASIC compiler project that has an active author and not something that lingers after the author leaves or dies? I see no downsides to everyone pulling together to make O2 the next gold standard of BASIC compilers.

[JRS]

For those Windows users that would like to try Linux but don't want to leave their favorite BASIC compiler behind, all works well under Wine. I installed the latest FBide from SourceForge using the .exe installation that also installs FreeBASIC. I wondered if I could compile the Oxygen.dll (in FB source) and it seems to have worked. It's even 13 KB smaller than the original. I have attached it if you want to give it a try. I replaced the oxygen.dll with the one I built and then tried to compile and run the glwindow example (O2 source) using the new oxygen.dll.





.

[Mike Lobanovsky]

1. Bob Zale was much, much younger when he ventured into Turbo Basic that has later on evolved into PowerBASIC the way we know it now - an industry standard BASIC with an extremely serious and professional user base.

This however didn't help him any. Bob is no more and PowerBASIC is likely to follow unless there are miracles still in stock for this ungodly and sinful world.

We're already one foot in the grave, every single one of us still tangible on forums like this. We may fail to make it if only out of sheer senility.

2. Looking into the future optimistically doesn't necessarily mean being unfaithful to Windows, at least to me. Being under Wine or ReactOS is essentially pretending to be under Windows. Then why don't you just install a decent version of MS Windows on your station natively, John, and enjoy it in its full glory instead?

Shorter binaries may simply mean poorer functionality of the environment. However hard the community tries, Wine (and ReactOS, for that matter) will always remain an unauthorised clone, a ghost lagging far behind the original.

We are not trying to emulate Linux under MS Windows, John, so why should the Linux community be so stubborn in trying to emulate Windows? Or is it still a manifestation of latent inferiority complex?

[JRS]

I have XP in a VirtualBox that until recently ran fine until the last MS update. (problem mentioned on the JRS forum) I also have Windows 7 64 bit installed in a separate partition. Why should I leave the environment I prefer and develop in just to run O2, FB, PB, ... applications that compile and run fine under Wine. Wine is less of an emulator than SysWOW64 is. If you need .NET under Linux, MONO seems to work with the Windows .NET apps I've tested. I also run all of the DOS BASIC's (PBDOS, QB 1.1, 4.5, 7.1, VBDOS) under dosemu that runs DOS better than DOSBox. (uses hardware visualization) My point is no reason to leave the farm.

Shorter binaries may simply mean poorer functionality of the environment.

That statement proves you're an interpreter author.  

Note - Please excuse the slow access times to the site. I thought we had it fixed with a resolver needing to be rebooted. Seems the problem has returned. My hosting provider will resolve the resolver issue in the morning.

[Mike Lobanovsky]

Yup, the lag as seen here may be as bad as 30 to 60 seconds depending on the action taken; very annoying...

My point is no reason to leave the farm.

Leaving the farm is exactly what you've been lulling us into one way or another for all the years that I've been watching your activity on the net.

That statement proves you're an interpreter author.

Not only that, John, not only that as you may see re-reading the annotations to FBSL's constituent languages.

As for the emulators, don't overestimate them as a whole and especially their graphics capabilities in particular. There are lots of Linux forks where hardware acceleration still remains beyond reach. What may seem acceptable for simple plotting with common BASIC graphics is certainly unacceptable for developing professional software. Leading video HW vendors co-operate with leading graphics OS development teams to provide HW-accelerated drivers but are reluctant to do that for minor OS'es and clones. Neither do they disclose sufficient information for 3rd-party devs to do that out-of-house. Reverse-engineering seems the only way out but it slows down minor OS development for years and in the meantime confines their graphics capabilities to VESA solutions only.

Developing serious graphics applications in an emulator is ridiculous. Emulators are for fun while genuine OS software with hardware virtualization officially supported where applicable is for real.

[Kuron]

Like with any new language (BASIC or not) good documentation or a broad set of example code is crucial to attract new interest to the project. I feel this is one of the biggest problems with O2 and the easiest to solve.

This is part of why I am here.  My own project recently collapsed due to financial reasons.  I have spent several months working on it in one way or another, whether working on game engine ideas or working on ideas for code examples or working on preliminary documentation.  So, rather than let things go to waste, I am considering jumping behind another project.  CBASIC is extremely intriguing, and as I told you before I really wish it had been around when I used to teach BASIC.  O2 is very interesting, but I also realize it is a very young language.  For me, a language needs to support 64-bit for Windows and it needs to be cross-platform and at least support Linux.  It also needs to be fast and produce tiny executable and be stable.  As soon as I can secure a new laptop, I will be putting O2 and CBASIC through the paces.

Talking about "noise" in an Intel chip is pure nonsense pretty much as is his refusal to buy a 64-bit Intel chip in an era when there are already generations of young people that have never seen a fossil 32-bit Intel chip with their own eyes.

If you want to get technical, those generations of young people have never seen a fossil 64-bit Intel chip with their own eyes, either.  Intel's 64-bit chips were atrocious and were all-but abandoned by the industry as the industry jumped behind AMD's 64-bit architecture.  Intel caved and now the 64-bit Intel chips we are all using are largely based on AMD's 64-bit technology.

We are not trying to emulate Linux under MS Windows,

Windows users are too busy emulating Windows on Windows.

[JRS]

Developing serious graphics applications in an emulator is ridiculous. Emulators are for fun while genuine OS software with hardware virtualization officially supported where applicable is for real.

OpenGL and ODBC are using native drivers under Wine. There maybe other services Wine does native that I'm unaware of. It's good enough to keep me from booting another partition or firing up a VirtualBox just to run a Windows app. There are only a couple DLLs I can't use from Windows if I run into a compatibility issue. Wines set of DLLs seem to work fine for most applications I run. Wine is constantly being updated when Linux does its update. With XP's funeral just months away, Wine is looking sweeter to a lot of users that can't swallow what Microsoft is now serving.

Yup, the lag as seen here may be as bad as 30 to 60 seconds depending on the action taken; very annoying...

I'm thinking of switching O2 to another IP. Every time the resolver has a memory overload, this site (IP) always seems to get hit where the other sites I host are fine. I keep a close eye on the sites I host so problems don't linger for long.

[Mike Lobanovsky]

...For me, a language needs to support 64-bit for Windows and it needs to be cross-platform and at least support Linux...
...Windows users are too busy emulating Windows on Windows. ...

Hehe, I know you're a seasoned Linux advocate as much as a renowned Windows adversary. Let me point out however that in my opinion, hardware virtualization of Windows XP under Windows 7 was a rather user-friendly and well-weighted solution implemented in the younger OS with respect to its elder and still extremely popular predecessor with an enormous code base in existence. Needless to say, both of them belong to the same brand. Hence we have never been, and still aren't, emulating anything; whenever we prefer to do so, we're using what's been designed especially for us and what's rightfully ours. Naturally, in exchange for our money as everybody's work should be adequately paid for.

Being a devoted MS Windows advocate, I can only wish minor OS'es all the best in their aspiration to catch up with the industry leader with at least some such manifestations of equal user-friendliness.

If you want to get technical...

Yes, I know the technical side of the story very well. Microlithography has been my bread for a very long period in my professional life. And I see nothing unusual or disgraceful in Intel's timely decision to switch to an alternative technology and polish it to perfection where AMD CPU's of compatible process geometries and clock frequencies were left far behind in terms of power consumption, die sizes, working temperatures, and throughput.

... Wine is looking sweeter to a lot of users ...

The key word here is a lot of. The key word when talking Windows is an overwhelming majority of.

OpenGL ... are using native drivers under Wine.

Sorry John but this is not so. Wine's OpenGL drivers are a wrapper around MS Windows DirectX. In other words, MS were generous enough to help their little bro (I'm talking about slack-baked graphical Linux here) out with some solutions that would lead it out of the dark of reverse engineering and VESA manipulations.

To sum it up, my point is as follows:

1. Oxygen Basic is Charles Pegge's prerogative until someone else decides to spawn their own fork and do with it whatever they see fit as is customary to open source projects on the net.

2. It's totally Charles Pegge's prerogative what programming instruments to use and what bitnesses and platforms to cover and in what order of priorities too as far as his own fork (or original, for that matter) is concerned. Should he even decide to confine Oxygen Basic as we know it to 32- and 64-bit Windows only then so be it.

3. Charles Pegge is a high-class professional and as such he is unlikely to base his decisions on, or be motivated by, some unenlightened judgements of unknown individuals on far-away forums.

4. There's yet too little practical support from the community to Charles Pegge as the only developer of Oxygen Basic to date, and I think any undue parallelism or perpendicularism will do no good. What he might need now most of all may be just loyalty and faith. At least this is what I know by my own experience.

Dixi.

[JRS]

Sorry John but this is not so. Wine's OpenGL drivers are a wrapper around MS Windows DirectX.

OpenGL and ODBC are using native drivers under Wine

Not true. Windows OpenGL is not being emulated under Wine. DirectX is processed (via DLLs) the same way it would under Windows. Please review this LINK for more details.

Wine is a compatibility layer capable of running Microsoft Windows applications on Unix-like operating systems. Programs running in Wine act as native programs would, without the performance/memory penalties of an emulator.

Myth Wine is not a "native" way to run a program and therefore inferior.

It is true that Wine is not a "native" way to run a program which is designed to run under Windows(tm). It is a way to run software designed for Windows(tm) on a different Operating System. This is useful in situations where one is unable or unwilling to run a Windows(tm) operating system. Cost, security requirements, and personal choice are some possible reasons for this to occur. Claims that software which is not run in a "native" environment is inherently inferior to software which is run in a "native" environment are spurious.

Software (i.e. Wine) is not inferior by virtue of not being written by Microsoft (native). One may use words such as "genuine" to perpetuate such a myth, but it is not something that most users care about. Most users care about being able to run a variety of software, of their choosing, which Wine lets them do.

[Kuron]

Hehe, I know you're a seasoned Linux advocate as much as a renowned Windows adversary.

You have that backwards.  I am a Linux newbie and life-long Windows user and supporter since its inception.  I also worked for Microsoft at one point after I left HP.  I am just an honest Windows user which often puts me at odds with the Windows fanboys over the past 29 years.  This last sentence is not directed at you, it is just a generalized statement.  I am NOT calling you a fanboy or implying you are dishonest.  However, many of the fanboys of any OS are indeed brutally dishonest, and we have all encountered those types.  Just because one is honest about the faults of an OS does not make one an adversary.   Quite the opposite.  Because of my love for Windows, this is why I have been so upset over the past few years about some bone-headed moves Microsoft made under the reign of Ballmer, that have seriously damaged Windows.

Let me point out however that in my opinion, hardware virtualization of Windows XP under Windows 7 was a rather user-friendly and well-weighted solution implemented in the younger OS with respect to its elder and still extremely popular predecessor with an enormous code base in existence. Needless to say, both of them belong to the same brand. Hence we have never been, and still aren't, emulating anything; whenever we prefer to do so, we're using what's been designed especially for us and what's rightfully ours.  Naturally, in exchange for our money as everybody's work should be adequately paid for.

I was not referring to XP Mode.  I was referring to the vast majority of Windows 7/8 users having to resort to emulation to run the vast majority of Windows software. 

As you point out, Windows is the younger OS and will always be playing catch up, so it is really not fair to ever compare Windows to Linux.  Heck, the biggest advancement in Vista was UAC which is something Unix had in 1969.

Being a devoted MS Windows advocate, I can only wish minor OS'es all the best in their aspiration to catch up with the industry leader with at least some such manifestations of equal user-friendliness.

Unfortunately, last year saw Windows damn-near dethroned and become an alternate OS in the consumer market (still top dog in the business market (except for the server market)) as consumers moved to tablets and other mobile devices, the majority of which are using an OS derived from Linux.  Even one of the biggest names in the PC gaming industry invested millions of dollars to move to Linux, which was my wake up call that I seriously need to start learning Linux and look into supporting it instead of bashing it.