BxbAsm

[jcfuller]

Steve,
  Duh it finally dawned on me as long as your routines are in a library you can use all the windows routines you want ( as long as there
is some way to do it in linux). It would be easier for me if you use msvcrt functions but no biggie.

James

[jcfuller]

Steve,
  check your yahoo mail.

James

[SteveA]

Right,
was out for the weekend.
Thanks James.

[SteveA]

James,
I converted all the "funct.c" functions into .Obj's and created a .Lib.
Do you want me to up load them ?
They are in a win32 format (STDCALL) and would probably need to be modified for for Linux.

Like so:

Code: [Select]

; *************BxbAsm Compiler*************
; Copyright: sarbayo (c) 2004-2012
; =========================================================================
  .486                       ; use 486 instructions
  .model flat, stdcall       ; Win32 memory model
  option casemap:none        ; case sensitive

 
  EXTERNDEF BffrInput:BYTE

  .code

chrstr proc
; --------------------------------------------------
  mov  esi, offset BffrInput
  mov  [esi], byte ptr al
  mov  [esi+1], byte ptr 0
  ret
; --------------------------------------------------
chrstr endp

end

Steve

[jcfuller]

Steve,
  Yes.
If the focus is for portability wouldn't "c" be better that stdcall?

James

[SteveA]

If the focus is for portability wouldn't "c" be better that stdcall?

As far as I know, in Windows, STDCALL is the default (required).

Once again, I don't see how a single piece of source code can compile as both Windows and Linux.
I must be wrong on this point, because I'm under the impression that Windows and Linux have very different requirements.

From my perspective, regarding portability, portability only exists in console mode.
As soon as GUI and the win32 API enters into the picture, there is no more portability.
So, I'm not overly concerned with portability.

The way I see it, there has to be two distinct versions: Win32 and Linux.
I must be missing something, as I see no way around it.

I can't base everything I want Bxbasic to do just on the 'C' RunTime Library.
Once I get a Linux machine up and running, I will be happy to learn what I have to, regarding the Linux API (if such a thing exists) and what it takes to get GUI working under Linux.

I have an entire section of code, that is exclusively win32 API based, that I am in the process of making into .Obj files at this time.

[jcfuller]

Steve,

As far as I know, in Windows, STDCALL is the default (required).

  You are correct in that STDCALL is the default in windows api but not with crt.

Once again, I don't see how a single piece of source code can compile as both Windows and Linux.

  I believe there can be both a Windows and Linux version using basically the same source (there may need to be a few IF WIN/NIX equates). Place all OS dependant code in a library with wrapper calls. One BxB.inc for each OS.

From my perspective, regarding portability, portability only exists in console mode.
As soon as GUI and the win32 API enters into the picture, there is no more portability.
So, I'm not overly concerned with portability.

There is no nix gui per se. All gui  is done through libraries (primarily gtk. nix is a text only system. You can program with
assembler and system interrupts just like in the old dos days but I see no reason to go there. (see the jwasm samples)

The more I look at IUP the more convinced I am that this would be the perfect compliment to BxbAsm for GUI.

I can't base everything I want Bxbasic to do just on the 'C' RunTime Library.

Examples?


I have not looked at the new code yet.

James

[jcfuller]

Steve,
  Do you have a working bxbasm using the library?
I tried replacing AFunct.c but Bxbasm.c would not compile?

James

[SteveA]

Do you have a working bxbasm using the library?
I tried replacing AFunct.c but Bxbasm.c would not compile?

Yes I do.
I'll wrap it up and upload it. I will need a little time.
I'll email you as such.
Now, this will only have been tested on Win, but it does compile.

Steve

[jcfuller]

Steve,

The BxbAsm code compiled fine with gcc.
The BxbAsm.exe translated the test1.bas to test1.asm.
Jwasm was able to compile test1.asm to test1.obj
polink was able to link test1.obj to test1.exe
test1.exe ran as expected.

Looking at the Bxbasm.lib asm modules and the bxbasm generated asm code it appears there is even more dependancy on the WinApi than in the last code I tested.

At this juncture, with the direction you are going I really don't see a Linux port.
I did try.
Bxbasm compiled fine on linux.
The resulting executable converted test1.bas to test1.asm after I saved all the files with unix lf endings.
I commented all the windows specific EXTERNDEF's in BXB.inc
jwasm compile the test1.asm to test1.o.

Many errors in the linking stage though.


Also the coding of the Bxbasm.lib asm modules has me scratching my head? Why all the globals instead of proc parameters?
I understand on input and string buffers but ....

James

[jcfuller]

Steve,
  I did get gcc to link test1.o -> test on linux.
My poor memory and lack of writing things down (or if I do forget where I put it) lead to the initial failure.

James
 

[SteveA]

Looking at the Bxbasm.lib asm modules and the bxbasm generated asm code it appears there is even more dependancy on the WinApi than in the last code I tested.

At this juncture, with the direction you are going I really don't see a Linux port.

Is this the current status ?

My upload labeled and dated: bxblinux-041612.zip
is as linux ready as I can make it.

My most recent upload: bxblinux-050112.zip
contains the same source files as the prior, with the exception that this list of files has changed:
bxblib.lib
bxb.inc
bxbasm.inc
...plus...
the addition of the .asm and .obj files.

Some of those (snuck back in and) were not intended for the Linux port and should be deleted and removed from bxblib.lib.
Some of those would be: clearscreen, locate, color, StdOut, StrLen, gdi_oldbrush, wherexy, etc.
In other words, any win32 related .obj's, just delete from bxblib.lib.
Sorry about that.

In their stead, the original or Linux specific code can be used.

Steve

[SteveA]

Also the coding of the Bxbasm.lib asm modules has me scratching my head? Why all the globals instead of proc parameters?

The EXTENDEFs and the associated global variables are system variables.
In some cases, they could be passed as proc parameters, but, then there would be no point, as they are global.
In a few cases I use a system variable as an expedient to standardize (make generic) procedures.
It's not hurting anything.

[John]

In other words, any win32 related .obj's, just delete from bxblib.lib.

ScriptBasic only has one source tree. The #IF meta statements for platform specific code works well for that project.

[SteveA]

In other words, any win32 related .obj's, just delete from bxblib.lib.

ScriptBasic only has one source tree. The #IF meta statements for platform specific code works well for that project.

Hey John,
Yeh,...
ifdef
  bla bla bla...
endif

works well, but, it turns into really ugly code (to me that is).

Here's what a snippet from stdio.inc looks like:

Code: [Select]

if _MSC_VER gt 1000
;#pragma once
endif
ifndef _INC_STDIO
_INC_STDIO EQU <>
if  0 eq defined(_WIN32) AND  0 eq defined(_MAC)
.err <ERROR : Only Mac or Win32 targets supported ! >
endif
ifdef _MSC_VER
;#pragma pack ( push , 8 )
endif
ifdef __cplusplus
;extern "C"
;{
endif
ifndef _CRTIMP
ifdef _DLL
_CRTIMP EQU <__declspec ( dllimport )>
else
_CRTIMP EQU <>
endif
endif
if ( 0 eq defined(_MSC_VER) AND  0 eq defined(__cdecl))
__cdecl EQU <>
endif
ifndef _CRTAPI1
if _MSC_VER ge 800 AND _M_IX86 ge 300
_CRTAPI1 EQU <__cdecl>
else
_CRTAPI1 EQU <>
endif
endif
ifndef _SIZE_T_DEFINED
size_t typedef DWORD
_SIZE_T_DEFINED EQU <>
endif
ifndef _MAC
ifndef _WCHAR_T_DEFINED
wchar_t typedef WORD
_WCHAR_T_DEFINED EQU <>
endif
ifndef _WCTYPE_T_DEFINED
wint_t typedef WORD
wctype_t typedef WORD
_WCTYPE_T_DEFINED EQU <>
endif
endif


I'd rather have two distinct (clean) versions of source code.