BxbAsm

[jcfuller]

Steve,
  I have  not done anything recently. My Linux 32bit box died and I have not fully set up the new one to do any Bxbasm testing.

James

[SteveA]

Aww,   
sorry to hear that.
Hope you are able to fully recover soon.

[SteveA]

Well, I guess I should post something..., lest people think I've quite working on this.

I've been busy working on a number of things, but, where it concerns Bxb, I've done a little bug fixing on Bxbasic just to make sure Bxbasic and Bxbasm function in a similar way. I don't want to be producing two seperate dialects.  As a reminder, Bxbasic is the core dialect that I'm working from.

Here's what I've been up to:
1) cleaning up Bxbasic (interpreter) and resolving some known issues,
2) continually working on Bxbasm and adding functionality, to bring it up to the level of Bxbasic,
3) working on some new documentation for Bxbasm,
4) tossing around some ideas for a new tutorial series and possibly a new revised and extended "Let's build a Scripting Engine/Compiler".

I've pretty much resolved my earlier issues with Jwasm. I think I've got it figured out. The Includes and Libs are kind of a mish-mash, but, maybe I can rework that for my purposes. I have found that, because of the way it was done, (or thrown together), some of the prototypes for functions and macros don't work correctly. So, when I encounter an issue, I just try to short-circuit the problem.

I originally thought I was going to have to reconstruct the Masm32 macros and utilities to make Bxbasm work, but, I've discovered that I really don't need them at all. I can just build the utilities I need and disregard the rest.

I have not produced an installation package, because I find I keep needing to make modifications to the Inc and Lib files. I suppose I can always add changes to the *updates*.

Over all, Jwasm (win32 ver.) seems to work quite well. That does bring up a couple of points:
1) I really would like to see a Linux version of Bxbasm,
2) I'm starting to add Win32 GUI stuff to Bxbasm.

Since I don't have a Linux machine setup, I guess I'm going to have to get one and figure out what the differences are.
Right now, Bxbasm can produce console mode apps without too much dependancy on Win32. However, if ported to Linux, there are a few things that may require ncurses. At least that's what I've heard.

If anyone is interested, I can upload the latest versions of what I've got at present. I should do it in two files, tho'. One for console mode only and a second with the new GUI/GDI stuff I'm adding.

Again, none of this is an official release, as none of it has been tested to any degree.
It works on paper!

Steve

[John]

If anyone is interested, I can upload the latest versions of what I've got at present.

I have a Ubuntu 11.04 32 bit box I can do some testing with and provide feedback. I have zero ASM background so unlike James, my feedback will be limited. Please zip/post a complete development package and let me/us know what dependencies might be needed to install from external resources.

[SteveA]

Hey John,
the asm part should either work or not work, assuming an x86, since much of it (console mode) uses the C library.

It's the Win GUI stuff that will present problems.
I'm not familiar with the Linux API's.
The only C on Linux programming I've done was console mode stuff with GCC.

[jcfuller]

Steve,
  I'm surprised John didn't mention it but I think using IUP for the gui might be the way to go.

James

[SteveA]

  I'm surprised John didn't mention it but I think using IUP for the gui might be the way to go.

Hey James,
I'm sure that using a tool kit could possibly solve a lot of immediate problems. Certainly it could speed up development.
I personally have refrained from using tool kits in the past and instead opted for native API code.
I think I would leave that choice up to the end-user. I don't want to create just another wx??? style program.
I would like Bxb to have as much of the API as possible to be intrinsic, or at least the ability to directly call any API function directly.

I've had some experience with this in the past, when I aided T. Chandler create a fork of Bxbasic that used Allegro, giving it GUI capability.
Allegro is okay, I just don't much care for the idea of depending on third-party Libs and DLLs.
I would like the language itself to be as robust as possible and let the end-user decide if they want to use a tool kit.

[John]

Steve,

What is your plans for external library support?

It would be nice to be able to use .h include files.

I think what James was saying about IUP is that it uses the native API for GUI. (win32api for Windows and Gtk for Linux)

John

[SteveA]

What is your plans for external library support?
It would be nice to be able to use .h include files.

I'm not clear what that means.
".h" = C header files.
How would that affect Bxbasm ?
Bxbasm is constructed using C, but, Bxbasm generates Assembler.
Do you want Bxbasm to be able to include C source code ?

I think what James was saying about IUP is that it uses the native API for GUI. (win32api for Windows and Gtk for Linux)

http://en.wikipedia.org/wiki/IUP_(software)

To me, (and I could be wrong) the Win32 API is native to Windows, at it's root.
GTK is a widgets tool kit, (much like wxWidgets and similar tool kits), and uses the native API, but is not the API.
No ?

Linux has it's own API, does it not ?
I would prefer to use it over a tool kit.
That's what I meant when I stated: "I don't want to create just another wx??? style program".

It makes no difference to me whether you call it wxCompiler/Interpreter or gtkCompiler/Interpreter or whatever.
I have no objection to Bxbasm being able to make use of widget tool kits, but, I don't want to build something that is dependant on them.
Like everything else that begins with wx or whatever prefix.
I guess programming with tool kits just doesn't impress me.
I'm not sold on tool kits.

[John]

If I wanted to add SQLite3 to my project, how would I declare the functions?

Gtk is your native GUI for Linux. (GNOME) There are others (KDE, X, ...) but Gtk 3 is the current standard.

[AIR]

I have no objection to Bxbasm being able to make use of widget tool kits, but, I don't want to build something that is dependant on them.

Same approach I took with MBC, so I agree 100%. 

[SteveA]

If I wanted to add SQLite3 to my project, how would I declare the functions?

Okay..., anything in a LIB can be compiled into Bxbasm.
So, if you have a LIB, that contains compiled functions, an .INC file can contain the prototypes.
Example:
    include C:\...\...\Include\bxblib.inc    ; list: prototypes

    includelib C:\...\...\Lib\bxblib.lib        ; library: compiled functions

Then, it's just a simple matter of calling the function directly with whatever parameters it requires.
In the case of DLLs, a function may need to be constructed to parse the parameter list and call the DLL in the proper manner.

Gtk is your native GUI for Linux. (GNOME) There are others (KDE, X, ...) but Gtk 3 is the current standard.

No problem.
I am confident that Bxbasm can be made flexible enough to work with any API and/or tool kit.
I'm just not familiar with the list of Linux API functions and what resembles or replaces the Win-API.

EDIT: re: SQLite3:
Ok..., I had to take a look at the sqlite3 header file.
A component of jwasm is a utility called h2inc. It scans ".h" (C header) files and converts them into ".inc" (assembly proto) files.
Then, it's a simple matter of linking Bxbasm with sqlite3.lib.
Example:
    include C:\...\...\Include\sqlite3.inc    ; list: prototypes

    includelib C:\...\...\Lib\sqlite3.lib        ; library: compiled functions

Call SQL functions normally, as you would in C.

[jcfuller]

Linux has it's own API, does it not ?

Yes and No. read up on xwindows - many in the know say it is one of the worst creations ever to be bestowed on *nix.

James

[jcfuller]

Steve,
  I'm trying to get back up to speed with bxbasm and was able to compile the last source (Feb 24?) on linux. Unfortunately it hung when trying to parse a source sample.
Will try again when you provide your latest updated source.

James

[SteveA]

Will try again when you provide your latest updated source.

Okay, that will be the next thing I do this morning.
Stay tuned, thanks.