Author Topic: Re: PowerBasic equivalents and conversions  (Read 12704 times)

0 Members and 1 Guest are viewing this topic.

chrisc

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #30 on: February 05, 2017, 08:35:08 PM »
Thank XXX you all

Mike is right, make use of C headers rather than converting the PB proprietary DDT or SDK. I don't think
Drake Software can launch its 64bit compiler anytime this year.  As they were only taken hold of the
source code on Jan 31 2017 and they were laden with many other loads from their own Taxation system (their main app)

One question is that does O2 compile to native machine code ?  Not sure, I heard that  compiled XOJO is actually in
p-code and only have a partial native code in its compiled exe files.

JRS

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #31 on: February 05, 2017, 11:06:21 PM »
Quote
Why not use C headers directly without conversion?

That makes the most sense to me as well.

The fastest way to a native Windows GUI is with IUP. These GUI toolkits exist for a reason.
« Last Edit: February 06, 2017, 09:14:58 AM by John »

Mike Lobanovsky

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #32 on: February 06, 2017, 02:27:11 AM »
Yes Chris,

O2 is a 100% native code compiler. BASIC source is transparently translated to equivalent assembly and then compiled by Charles' core x86/x64 assembler either statically to an on-disk EXE file or dynamically into the process memory. The former mode is primarily used to deploy the solution while the latter one is more handy at the project development and debugging stage. Otherwise the resultant executable machine code is absolutely identical.

JRS

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #33 on: February 06, 2017, 09:58:36 PM »
Mike,

Would FBSL be a closer match to PowerBASIC than O2?


Charles Pegge

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #34 on: February 07, 2017, 02:45:26 AM »
Hi Roland,

Re: LV_StatusBar: negative equates / 64 bit compiling

The problem traces down to NMLV.hdr.code being defined as a 32 bit UINT. So you are effectively CASE testing 64bit integer numbers against a 32bit uint.

The solution is to cast the select as int, to enforce  64bit sign-extension

SELECT CASE (int) NMLV.hdr.code

Code: [Select]
        SELECT CASE (int) NMLV.hdr.code

          CASE LVN_ITEMCHANGED
              ' when a check box is checked or unchecked it displays
...






Charles Pegge

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #35 on: February 07, 2017, 03:41:35 AM »

Hi Chris,

To follow on from Mike: OxygenBasic was built from machine code - the ultimate bottom-up. The original o and o2 were opcode languages, and became embedded in built-in linker. Assembly code came next, then a macro layer for high level assembler. Then the macro layer was extended to create BASIC.

But I seriously underestimated the complexity of high level languages. It has taken much longer to get there than I originally anticipated,  back in 2008 :)

Mike Lobanovsky

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #36 on: February 07, 2017, 11:03:36 AM »
John,

No, FBSL's BASIC is an interpreter and as such takes much more after VB than PB not only in terms of speed but also in terms of vocabulary and built-in functionality. FBSL's two integral machine code jitters expect their source code to be written in plain ANSI C and Intel style assembly and there's no automatic BASIC-to-C or BASIC-to-Asm translation possible in the current version of FBSL. The three languages can however co-operate at the function level within the same multi-lingual FBSL script passing objects and values to and fro via function arguments and returns and/or sharing them in the same process memory via their pointers.

JRS

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #37 on: February 07, 2017, 11:25:53 AM »
I don't see interpreters being second class citizens when they can easily switch to C or ASM for critical sections of code. 90% of most applications are running idle. Script BASIC for example did the PB array split in .02 seconds including load, tokenizing, and writing out a file. How fast does it have to be?

Mike Lobanovsky

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #38 on: February 07, 2017, 01:46:35 PM »
"The faster the better" and "Small is beautiful" are my mottos. :)

JRS

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #39 on: February 07, 2017, 07:47:41 PM »
"The faster the better" and "Small is beautiful" are my mottos. :)

I don't know if that motto would fly with your wife.  :-*

Arnold

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #40 on: February 08, 2017, 12:19:18 AM »
Thank you Charles. Small cause great effect.

Quote
SELECT CASE (int) NMLV.hdr.code

I use some more code of this kind which select negative constants and which must be adapted for 64bit compatibility.

Roland

Arnold

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #41 on: February 08, 2017, 01:37:45 AM »
Hi Chris,

as there are some demos with menus provided with Oxygenbasic there should be no problem. My interest here was to create menus within dialogs (like in the powerbasic code) using a resource file which I created with Resed.exe.

I did not implement the back colors of the menu which seem to need the MENUITEMINFO structure and SetMenuItemInfo function. But I was interested in the MessageBoxIndirect function. Also in accelerators (like F1, Ctrl-O, Ctrl-S) which cannot be used with DialogBox, so I used the CreateDialog macro instead.

Attached are the project files and a 64bit executable as a zip file. There is also a batch file which builds the exe file. (OxygenBasic is expected in c:\). Simp_menu.o2bas will create a 32bit exe, for a 64bit exe these lines must be changed to:

Code: [Select]
'Create Exe File: uncomment executable
'32 for Win32, 64 for Win64
' executable("Simp_menu.exe",32)
 executable("Simp_menu.exe",64)

I developed the project creating a dll like I did with LV_StatusBar. To create a standalone executable I used this trick:

Code: [Select]
...
/*
sys hResources = loadlibrary "Simp_menu.dll"
if not hResources then
  mbox "Error: Simp_menu.dll not found"
  ExitProcess(1)
end if
*/

hResources = hInstance
...

In this way I can create and modify the resources in a dll, can develop and debug the main code and later put everything together in a single file. But of course this is only one way to achieve this goal, many roads lead to Rome.

Roland


.

Charles Pegge

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #42 on: February 08, 2017, 02:49:32 AM »
Thanks Roland,

I hope that unsigned integers being evaluated for negative values are rare!

I have also resolved the hiword(lparam)-20,  parameter problem, which turned out to be a missing cr in Oxygen's 64 bit parameter Asm encoder. I will post a new OxygenBasic update soonest.
« Last Edit: February 08, 2017, 03:00:30 AM by Charles Pegge »

Mike Lobanovsky

  • Guest
Re: Re: PowerBasic equivalents and conversions
« Reply #43 on: February 08, 2017, 10:28:28 AM »
I don't know if that motto would fly with your wife.  :-*

Which one of them? I've had a few. ;)

chrisc

  • Guest
Re: PowerBasic equivalents and conversions
« Reply #44 on: February 08, 2017, 10:39:57 AM »
ThanX sirs for your code and info on O2

I need to know where can I find documentation like  user guide for O2 for beginners like myself.
I'm doubtful that  PB will ever take off again under the new management.  They haven't even responded
to my emails for more than a week.