Windows Explorer right-click menu for .BAS files fails in Windows H8.1

[Yet Another Troll]

After installing X11-Basic-1.26-55-unstable-setup.exe over the previous installation of X11-Basic-1.25-50d-setup.exe, the right-click open or edit operations on .BAS files fails. Open brings up a console for a split second which disappears before I can see what it might be, as does "View docu". Edit brings up Notepad with an untitled, empty file. In Regedt32, the X11-Basic shell New/"&Edit" command is C:\windows\SysWow64\Notepad.exe with no quotes or "%1" file name placeholder, open is "C:\Program Files (x86)\X11-Basic\xbasic-wrapper.bat" "%1" "%2" "%3" and ViewDocu/"&View docu" is C:\Program Files (x86)\X11-Basic\xbasic-wrapper.bat "-doc_%1"

Attempting to EDIT from within X11-Basic fails due to $EDITOR not being set and rm not being recognized as an executable, leaving a .bas.~~~ temp file lying around.

Opening a .BAS file with Notepad the hard way shows the entire file on one line. WordPad doesn't, but saving it from within WordPad inserts blank lines between every line of code, and so when it's then LOADed in xbasic, there are problems with lines split with \ .

The interpreter doesn't mind spaces accidentally added after \ in split lines, but the compiler hates them and issues a cryptic syntax error.

The best development process seems to be to do primary development within Android and then copy the completed application, whether source or perhaps byte code to the Windows machine, in a hilarious inversion of the usual cross-development scenario.

[Markus Hoffmann]

Yes. The WINDOWS version is most neglected by me. This is because I do not own any computer running WINDOWS. So I always have to test the stuff on a friends comupter. Which is very uncomfortable. I am looking for a maintainer for the WINDOWS-Version, but until now, nobody has volunteered.

[Yet Another Troll]

I don't know about stepping up to help maintain the Windows version, but I'm open to suggestions about what might need more testing. FORK and PIPE maybe? I'm looking at ways to parallelize the palindromic subsequences program even if threading support in the interpreter and bytecode VM ends up being a version 2.x feature.

[Markus Hoffmann]

Well, I think the user interface is most important. How to open a file, write a program, access documentation, compile the program to an .exe. There should be no obstacles, otherwise nobody would want to use it. A competitor is "yabasic" (an interpreter) but I think X11-Basic is already better. ALso "freebasic" (a compiler) is very popular on WINDOWS.

[Yet Another Troll]

Would ReactOS be an option?

http://reactos.org/

Is Android x86 popular enough to target?

http://android-x86.org/

[Markus Hoffmann]

I do not know it. So it would also be hard for me to target it and test it. I always wantet to target NodeMCU, because I own some, but I had no pressure to do so so far.

[Yet Another Troll]

Are you hinting I should apply pressure about the Len(Huge$), Mid$(Huge$, x%, y%), etc., thing? While I can work around it, it is a pain point for me.

[Markus Hoffmann]

No not really, because the parser cannot handle it this way. One could introduce new functions STRLEN() or something like that, which can take only(!) a variable reference as argument (and not an expression). But maybe the workaround with ARRPTR() and BMOVE could do well enough:

' This function is faster than MID$() if the string is longer than 
' 100000 Bytes (interpreted) or 20000 bytes (compiled).
function fast_mid$(VAR t$,a,b)
  LOCAL ret$
  ret$=SPACE$(b)
  BMOVE VARPTR(t$)+a,VARPTR(ret$),b
  return ret$
endfunction

[Markus Hoffmann]

We could either introduce a function STRLEN(svar$) or VARLEN(var), or a function STRPTR(svar$).

STRLEN would be streight forward: return the length of the string.

VARLEN would be more general: return the amount of bytes belonging to the content of the variable. this would return 8 for float variables and 4 for int variables, and maybe some useful value for arrays.

STRPTR would return a pointer into memory where the length could be received from with LPEEK(). Also the pointer of the string could be LPEEKed here but this is redundant, because the adress can be obtained also via VARPTR().

All three options would be consistent with the concept of X11-basic. Personally I would have liked VARPTR to point to a structure describing the variable instead of pointing to the content of the variable, but VARPTR is used in other BASIC dialects and so part of the BASIC "standard". To be compatible with them, it must point to the content.

[Yet Another Troll]

Then I may as well cobble up a virtualized huge string library like I did for Xenix/286. Its malloc() could only return buffers less than 32KB in size, but if you broke a huge string up into arrays of 4KB or 16KB chunks or so, and perhaps swap unused chunks out to disk files, ...

[Yet Another Troll]

Why is the parser making unneeded copies of strings though? Sure, the result of A$ + B$ must needs be evaluated and stored before being passed to LEN(A$ + B$) but why does C$ need to be copied before evaluating LEN(C$) ? If ref counted strings is an xbasic 2.0 issue, that's OK.

[Markus Hoffmann]

The parser operates on values not on references. So it takes the content of C$ and passes it to LEN(). VARPTR() would be different, here the content ist the reference to the variable. Therefor VARPTR(a$+b$) would not work. BTW: my favrite would be VARLEN().

[Yet Another Troll]

VARLEN() would work for me too. Thanks!