• Welcome to Jose's Read Only Forum 2023.

PluriBASIC - Progress March 7 2018

Started by Brian Alvarez, March 08, 2018, 03:58:28 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Brian Alvarez

 Until now, the engine could compile 64 bit applications with no problems. However since the engine was using plain "string" strings, the calls to external DLL's crashed.

Today i decided to make a big step and started implementing BSTR as the default string type.

It is a challenge because now the engine must do much more to compare, concatenate and in general, handle the strings.

The benefits are that PluriBASIC will support Unicode, as well as being compatible with external DLL's and producing highly compatible DLLs and C++ SLLs, aka LIBs.

When i finish this, i would like to handle the array order to handle the params backwards. If you know what i mean. This will increase the compatibility with external stuff.

Brian. :)

Brian Alvarez

Done. The engine now uses BSTR's. Yay!

Brian Alvarez

The string data types supported are:

STRINGZ (char)
WSTRINGZ  (wchar_t)

They all interact correctly when compared and concatenated.


Theo Gottwald

Sounds good!
Can you cooperate with other programmers who are working on such projects - for example
- Charles Pegge (Oxygen)
- James C. Fuller (bc9Basic)
such a Cooperation would speed up things significantly. Especially as you come now to the part where you need to be compatible
with APIs, DLL's from other Languiages and such.

Chris Chancellor

Brian,  this  O2 Charles Pegge is a maestro and he can help out on your project.

You should register as a member in oxygen basic and see what you can come up with a better product 

Charles Pegge

I would warmly welcome any compiler development that needs a back-end. Oxygen.dll (141kb) provides all-in-one basic compiling, assembly and linkage, both for PE files and direct JIT execution. The benefit to the Oxygen party would be to establish the best protocols and techniques for creating new compilers :)

The core functions are the minimum required for BASIC, and uses ole strings, like PowerBasic and thinBasic.

It is quite easy to add extensions and specialised syntax such as DDT, which can be decomposed into standard procedures.

As an example, here is our current co2 compiler source (4k), using oxygen.dll.

'Compiler for OxygenBasic

'Charles Pegge
'12:53 11/06/2015
'10:17 06/03/2017
'15:26 13/01/2018

  #file "co2.exe" 'Oxygen dependent compiling
  uses SysUtil
  uses console

  extern lib "oxygen.dll"
  uses oxygenAPI
  end extern

  BufferObject pr

  sys    a,i
  string s,t,u
  sys    swa,swc,swm          'COMPILER SWITCHES
  string fname,mname,xname    '1st FILE NAME COMPONENTS
  string bfname,bmname,bxname '2nd FILE NAME COMPONENTS
  string er                   'ERROR MESSAGES
  s=lcase CommandLineArgs()
  if not s then goto nofile
    i++ : skiplspace s,i
    if ascb<>45 then exit do
    i++ : skiplspace s,i
    select ascb
    case "i" : swa=ascb '-i intermediate output
    case "a" : swa=ascb '-a asm output
    case "b" : swa=ascb '-b o2 output
    case "c" : swc=ascb '-c compile
    case "m" : swm=ascb '-m do not show messagebox
    end select
  end do
  s=mid s,i
  nofile: 'check
  if not s then
  pr.in "
  compiler options:
  <filename>       compile and execute directly in memory
  -a <filename>    list assembly code
  -b <filename>    list o2 machine script
  -c <filename>    <optional filename>  compile to a binary
  -i <filename>    list intermediate code
  -m               output to console
  jmp fwd done
  end if
  i=1 : xname=".o2bas" 'DEFAULT SOURCE EXTENSION NAME
  t=getfile fname
  if not t then
    pr.in "error 3: file empty or not found: "+fname
    jmp fwd done
  end if
  if swc then
    if bfname="" then
    end if
    u+="#file "+qu+bfname+qu+cr
  end if

'o2_mode 0  'read/return null terminated ascii strings
  o2_mode 9   'ascii string (1: byte characters) (8: o2 string)
  select swa
  case "a"  : pr.in o2_prep(t) 'OUTPUT ASSEMBLY CODE
  case "b"  : pr.in o2_view(t) 'OUTPUT O2 MACHINE SCRIPT (AFTER ASSEMBLY CODE)
  case else :       o2_basic t 'COMPILE TO EXECUTABLE BINARY
  end select
  if er then
    pr.in cr+ er
    jmp fwd done
    if swc=0 then
      o2_exec 0
      pr.in cr+"Okay"
    end if
  end if

  sys ho,lew
  string prs=pr.out
  if len(prs) then
   if swm=0 then
      mbox prs
      'sys p=GetCurrentProcess() '-1 parent process
      AttachConsole(-1) 'attach to console of parent process
      output prs
      sys ho=GetStdHandle( STD_OUTPUT_HANDLE )
      if ho<>consout then consout=ho : output prs 'windows 10
      sleep 10
    end if
  end if

Brian Alvarez

Hello Charles, what is oxigen? The syntax looks very different to what i am aiming to...
Can you ellaborate?

By the way, i already implemented ARRAY SORT. Im very close to compiling PluriBASIC in itself as a 64 bit compiler.

Charles Pegge

Hi Brian,

Oxygen understands the Qbasic/PB genre of Basic syntax, but has additional flexibility, including C notation. It could replace any dependencies on PB or a C compiler at the back-end.

Chris Chancellor

Hello Brian

PB commands can  be converted directly to Oxygenbasic O2 commands and then  be compile to 64bit exe and dll assemblies

and that O2 also allow for inline assembly which has all the features of PB inline assembly codes.

see the http://www.oxygenbasic.org/forum/index.php
for yourself

and download its latest compiler and sample from

Brian Alvarez

PluriBASIC is prepared to output code for any platform. So, even if i added an Oxigen mode, i would still like to finish the C++ version.
I also know Qbasic, maybe that will help. I will take a look when i have the chance. :)

Chris Chancellor


As long as your IDE can produce 64bits native code  from PB source code, it would have tremendous
advantage over others. Alternately  if it can emit O2 source codes for which we can later recompile to
native codes it would be godsend also.

we need native compile exe and dlls bcos they are harder to hack than those MS intermediate language IL
from VB.Net and C#.   the MSIL are in clear text format and any source code it contains can be easily
extracted out by hackers. 

it is the time saving that matter most in any given established company where there are thousands
of programs that need to be converted to 64bits.  I heard of a company which has only converted
some 40% of its codes from PB to Purebasic after a 4 year + non stop conversion effort and he has
3 programmers working full time on it.  sadly the Purebasic language is very weird and this explains
the difficulty involved for this conversion, Purebasic syntax is very different from other basic languages,
it is like going against the grain task to do the conversion. 

this means that there will be a very high demand for your product if you can produce an IDE converter
that can convert 60 to 70% of the PB programs to native 64bits code.

Just join us at the O2 forum, and you will be able to write the O2 code that you needed.  i myself has already
converted more than 10 of company programs to O2.

Brian Alvarez

 I might. However, PluriBASIC can already compile 64 bit apps with the help of a c++ compiler.
I am now working on making it compatible with Jose's api headers. I only have two hands, and
my partner is currently away from any computer. Its still going to be a while.

However, i tend to disagree. I have barely seen any interest in it. Quite the contrary. I am doing
it as a hobby, and it might prrobably never see the light of day. Who knows. But i will still finish it.

  As a compiler developer, i kind of understand the point of view that Bob Zale once expressed. Creating
a compiler is a huge load of work and if there is not enough market for it, it is not worth it to focus in it.
Unfortunately i also need to make a living and the kind commends of 5 or 6 people, althoug VERY
APPRECIATED, is not enough to invest such long time into the creation of it.

Even less if the effort i am putting into it is obscured by the ominous situation of releasing it.

Should an investor with $$ appear, i could focus in it (And I openly express it with the intention of
attracting someone to jump in) and finish it much faster.

As things are right now, im just a guy with big intentions but very little time. If i had $$ i would invest in
it to even give it away for free. But that is a luxury i unfortunately cannot afford. :(

This said, PluriBASIC is prepared to add new languages in very little time. I could probably add Oxigen
basic support for it probably in the time i take to lear it + a week to implement it, but i have a tiring job
i need to attend.

Mike Lobanovsky

Quote from: Brian Alvarez on April 28, 2018, 09:14:15 PM... probably in the time i take to lear it + a week to implement it ...

You're obviously underestimating the O2 learning curve. It's a mature low-level BASIC-like language that takes time to master plus probably as much time to select and test thoroughly, among its many features, the ones that would best fit your needs to re-implement PB's higher level functionality to any practical degree of usability.
(3.6GHz Intel Core i5 w/ 16GB RAM, 2 x GTX 650Ti w/ 2GB VRAM, Windows 7 Ultimate Sp1)

Brian Alvarez

Quote from: Mike Lobanovsky on April 29, 2018, 12:54:43 AMYou're obviously underestimating the O2 learning curve...

I didnt mention i would learn it quickly, so i am not underestmating it's learning curve [time?]. That time could be much more than a week. <playfulness>Or probably less? Probably you are also underestimating my humongous I.Q. ;) Hehehe. Jk. </playfulness>

Anyway, im sure i could have the fundamental basics of O2 (like if/then, for/next), in a couple nights. Maybe i will have a chance to prove it next weekend.

Brian Alvarez

 I took a look at oxigen basic, and it looks like a BASIC-C++ hybrid.
PluriBASIC should not have any issues generating code for it.

Charles, Where can i find information for invoking the dll function for compiling the generated code?