The future of 'BBC BASIC for Windows'

[Hated Moron]

On 15/07/2023 21:47, Maksim AbuAjamieh wrote (cross-posted from the discussion group):

there is always a way, just like there is dosbox or pcbasic for GW-BASIC fans, there is always a way to enjoy your development environment/software be it wine for Linux or a virtual machine, etc.

My concern is for the future of BBC BASIC. Of course earlier versions, whether it be Sophie's original 6502 version (1981) or her ARM BASIC (1986) or my BBC BASIC for Windows (2001) all represent important milestones in the development of the language, and it is possible to run them on appropriate emulators (and probably always will be). But they don't represent the future of the language.

Promote the SDL version as you like, just leave BBC4W and its community out of this.

That is ridiculous. This thread is specifically about trying to incorporate in BBC BASIC for SDL 2.0 some of the features of BB4W which set it apart and currently cause people to choose it over BBCSDL. Those features include support for the Windows 'look and feel' (e.g. GUI controls) accessing Windows-specific DLLs (maybe for specialised I/O purposes) etc.

Who better to involve, and ask for help, than those in the 'BB4W community' who use those features and chose BB4W precisely because of them?

In suggesting that the 'BB4W community' is somehow distinct from the wider BBC BASIC community, and that its needs are better served by being isolated from developments elsewhere, you are doing a disservice. There has indeed been a regrettable tendency to encourage the belief that BB4W and BBCSDL are more different than they actually are, with the effect of making people think they need to choose between them.

The truth is that, by design, BB4W and BBCSDL are remarkably similar in their capabilities and the interfaces they present to the programmer, especially given the differences under the hood. A very large number of programs will run equally well on both, but sometimes with BBCSDL being much faster. What few differences there are enrichen the language and broaden the range of possible applications. The more people who use both the happier I will be.

Otherwise you will destroy your own legacy.

What is that supposed to mean? That when I'm gone people will look back and say that by trying to develop a more capable Windows edition of BBCSDL, and give it a more sustainable future, I damaged BBC BASIC? Seriously?

[Hated Moron]

I don't know how widely shared Maksim's opinions are - hopefully not at all - but they are based on a serious misunderstanding of how computers, operating systems and applications work. Although I have covered all this before, I will once again attempt to set the record straight. Those who need no convincing can look away now.

The claim being made is that BB4W and BBCSDL are somehow fundamentally different, and that the existence of (or developments in) BBCSDL in some way threaten BB4W or may force BB4W programmers to adopt new ways of working which they would rather not. This is an entirely false narrative, the truth is that BB4W and BBCSDL share much more in common than what divides them.

Firstly there is the BBC BASIC interpreter itself. BBC BASIC for Windows and the 32-bit x86 editions of BBC BASIC for SDL 2.0 use the same interpreter - the code is identical (written in x86 assembly language which is converted to machine code using the NASM assembler). There are no differences at all in respect of core BBC BASIC language features.

Then there is the operating system: both BB4W and the Windows edition of BBCSDL run in Windows. Yes, BBCSDL has an additional 'abstraction layer' - SDL2 itself - which sits 'between' the application and Windows so as to provide a unified API across multiple platforms, but that does not block access to Windows. You can 'bypass' SDL to gain access to the underlying Windows API using SYS, in a very similar way to how you can in BB4W.

Finally there are the input-output features such as file-handling, network access, graphics (2D, 3D, antialiased, shader), sound, physics simulations etc. BBCSDL has been designed such that these are as compatible as possible with BB4W, either by means of built-in statements and commands or libraries. It's this that enables such a large range of BASIC programs to run on either BB4W or BBCSDL with no modifications at all.

So how do BB4W and BBCSDL differ? The most significant difference is in respect of library dependencies. BB4W is dependent only on standard Windows DLLs which are included with every Windows installation. This is what makes possible extremely compact executables (often smaller than 100K) because they need contain only the interpreter, minimal code to interface the interpreter with the Windows API, and the user's BASIC program.

The Windows edition of BBCSDL has some of those same dependencies but in addition needs the SDL2, SDL2_ttf and SDL2_net libraries. They are relatively large and must be included with every 'compiled' program; the minimum size of a BBCSDL standalone executable is about 1.5 Mbytes. For demonstration purposes you can download just such a program here.

Secondly there is the graphics subsystem. BB4W uses GDI32, which uses the CPU for rendering, whereas BBCSDL uses OpenGL, which leverages the GPU, often with a significant speed benefit. But although these are very different under the hood BBC BASIC presents as far as possible a uniform interface to the programmer. The main residual difference is that OpenGL calls must be made from the UI thread whereas GDI32 calls can be made from a worker thread, so occasionally the BBC BASIC programmer needs to ensure thread synchronisation.

Although BB4W is specifically suitable for creating programs which have the Windows 'look and feel' (since they use native Windows controls for the UI, such as dialogue boxes and the like) there is no fundamental reason why the Windows edition of BBCSDL shouldn't do the same. And that is what this thread is all about - attempting to port the existing BB4W UI libraries (principally WINLIB*.BBC) to BBCSDL. There may be pitfalls, but we won't know until we try.

So, BB4W users, please don't think of BBCSDL as a threat. Please don't feel that anybody wants to force you to switch from BB4W to BBCSDL, nothing could be further from the truth. The objective being pursued in this thread is to support the Windows look-and-feel in a product which has a more sustainable future than BB4W, in respect of being 64-bit compatible and Open Source. I encourage you to try BBCSDL, you will hopefully be pleasantly surprised at just how familiar and compatible it is.

And, yes, if you are so inclined, please volunteer to help discover how practical it may be to imbue BBCSDL (in Windows) with some of the features of BB4W which currently make it unique.

[Edja]

...port the existing BB4W UI libraries (principally WINLIB*.BBC) to BBCSDL

I've managed to write some useful programs over the years in BB4W under Windows. But I wouldn't know how to write the equivalent using BBCSDL without the WINLIB libraries. So, I'd love to see their availability in BBCSDL.

...you can 'bypass' SDL to gain access to the underlying Windows API using SYS

The other library I can't do without is COMLIB. As you know I use this intensively to interact with Excel. A long time ago (2012) you worked on this together with M.G.Marten. Is there any hope that you (or someone) would make COMLIB available 'bypassing' SDL?

I fully understand the rational to move to BBCSDL. I recognize the many advantages this offers in terms of speed, cross platform OS support, open source, long term maintainability ... I will jump to the occasion to move my programs to BBCSDL once the above will be available.

the usual response to this kind of plea is apathy.

Not so sure about the apathy. I'm convinced a majority of BB4W and BBCSDL programmerss would be willing to step in. However, 98% of them are users (as I am) and not system programmers.
The only support I can offer is testing these libraries with my programs. But that comes later in the chain. Today you need help to port these libraries. I'm afraid I am 'just' one of these users. I hope the "system programmers' will step up to the challenge.

Edja

[Hated Moron]

But I wouldn't know how to write the equivalent using BBCSDL without the WINLIB libraries.

It all depends on how important it is that your programs have the Windows 'look and feel'. If you've used the WINLIB* libraries to generate dialogue boxes, edit controls, menu bars etc. then it should be straightforward to use the similar BBCSDL libraries: 'dlglib.bbc', 'editbox.bbc', 'menulib.bbc' etc. The resulting controls won't look or behave exactly like native Windows controls, but they will have similar (if often simplified) functionality.

I've ported several programs from BB4W to BBCSDL this way, where the originals used the WINLIB* libraries, and it has been quite easy. If you've played with SDLIDE you will already have experienced controls made this way, I use it every day and barely notice the difference. So to suggest that you need the WINLIB* libraries to create programs with a modern graphical interface is quite wrong.

Indeed you should already be familiar with SDLIDE_for_BB4W, the entirely free, non-memory-limited version of BBC BASIC for Windows which uses SDLIDE as its IDE. That will give you an excellent introduction to the kind of User Interface that you can easily achieve now in BBCSDL, whilst still having the familiarity of being BB4W under the hood.

So if it's essential to you that your programs have the Windows look-and-feel you will need to wait until the WINLIB* libraries are ported to BBCSDL, if that proves possible. But if you simply want to avoid having to learn how to use the similar existing BBCSDL libraries I have little sympathy. Learning new things is part-and-parcel of programming!

The other library I can't do without is COMLIB. As you know I use this intensively to interact with Excel. A long time ago (2012) you worked on this together with M.G.Marten. Is there any hope that you (or someone) would make COMLIB available 'bypassing' SDL?

Do you know for sure that it doesn't work in BBCSDL now (with trivial changes such as adding the A suffix to function names that need it)? It's not at all obvious to me that it wouldn't work, at least for a subset of the kinds of things it gets used for in BB4W. An example would be speech synthesis (Text-To-Speech); although I haven't tried it I can't see any reason why it shouldn't work.

So I would say give it a go rather than assume it won't work. The few 'essential' changes that I've previously outlined (adding the A suffix, explicitly loading the DLL if it's one which is loaded as standard in BB4W but not BBCSDL) are purely 'mechanical' and don't require any knowledge of how the library works in detail. Anyway in the case of COMLIB nobody understands that any more, certainly not me!

However, 98% of them are users (as I am) and not system programmers.

Writing a WINLIB* or COMLIB style library from scratch may require a "system programmer" but porting one from BB4W to BBCSDL doesn't! A degree of understanding of how the original works may be helpful, especially if the ported version doesn't work and needs to be debugged, but isn't necessarily essential. You may be pleasantly surprised by how easy it is, especially in the case of COMLIB.

Give it a go, if it doesn't work I'll try to help you debug it.

[Hated Moron]

Give it a go, if it doesn't work I'll try to help you debug it.

Are you going to try porting COMLIB.BBC to BBCSDL?

[Edja]

Are you going to try porting COMLIB.BBC to BBCSDL?

Yes, but read on...

I will jump to the occasion to move my programs to BBCSDL once the above will be available

My initial idea was to try to do the move IF the required libraries came available. You argument that I could port COMLIB myself (with your debugging support). I'm not downplaying my programming skills (as a user !!) but let's stay realistic ... I had a look at the existing COMLIB code and I only have a vague and partial idea how it works. I wouldn't know how to find/install/call the equivalent dll module(s) from BBCSDL.

Statements such as

Code: Select all

      SYS "LoadLibrary","OLE32.DLL" TO O%
      SYS "GetProcAddress",O%,"CoInitialize" TO `CoInitialize`
      SYS "GetProcAddress",O%,"CoUninitialize" TO `CoUninitialize`

and

Code: Select all

      SYS !(!O%+24),O%,F%,I%,`LCID%,T%,D%,U%,0,0 TO R%

make my head spin and this is just a sample...
I'll have to map the SYS calls to the SDL equivalents. Let me assure you this is far from trivial to me.The way you've explained it (adding the A suffix to function names) makes this sound easy. Surely there must be more to it!
My programs do run nicely in BB4W. Also, I'm more optimistic than you that existing 32bit environments, including BB4W, will continue to run. Microsoft has a decent reputation in this respect.
Apart from a willingness to help out, there is no pressure for me to start studying BBCSDL.
In about two weeks I'll be leaving on a 10-day vacation to Italy. Then I'll be back for 3 weeks and then to Italy, again, until end of September. The point is: my time to devote to programming will be quite scarce for a while.

So, when I say "YES" (first line of this reply) and taking all the above into consideration (technical issues and my vacations) it should be clear that this will take several months, if, at all, I can get my head around it.

As a first step I'll write a down-to-earth program that relies on a few very simple COMLIB-statements and startup Excel. Once debugged I'll see how to adapt COMLIB to make the program run with BBCSDL....

You may be pleasantly surprised by how easy it is, especially in the case of COMLIB.

I like pleasant surprises but as a precaution I'll reserve the right to give up If the challenge proves to be to steep .

Learning new things is part-and-parcel of programming!

So true
Kind regards,
Edja

[Hated Moron]

Statements such as

Code: Select all

      SYS !(!O%+24),O%,F%,I%,`LCID%,T%,D%,U%,0,0 TO R%

make my head spin.

Of course they do, they do mine too; I've said that I no longer understand how COMLIB works and that's perfectly true. But you won't have to change that code at all, unless you contemplate making a 64-bit-compatible version of the library. That would indeed be useful in the long run, but will be a great deal more difficult and is not what I am expecting at this stage.

I'll have to map the SYS calls to the SDL equivalents. Let me assure you this is far from trivial to me.

But I've already told you that no such changes should be necessary! I'm afraid this is an all-too-common problem: for whatever reason people worry that things will be much more difficult than they actually are (or at least should be). It gives them an excuse not to try, which is perhaps the reason, but it is frustrating to me.

The way you've explained it (adding the A suffix to function names) makes this sound easy. Surely there must be more to it!

There you go. You are so convinced that it will be difficult/impossible that you refuse even to believe me when I explain what is necessary,

I'm more optimistic than you that existing 32bit environments, including BB4W, will continue to run. Microsoft has a decent reputation in this respect.

Maybe, maybe not. At the stage when every other major OS is 64-bit only, which can't be long in coming, it will depend on whether Microsoft sees continued 32-bit support as a sufficiently strong business case or not.

But just as important as the 32-bit issue is whether BBC BASIC has a future. Whatever some people may like to believe, the language itself, whilst interesting, has no features that sufficiently distinguish it from others (whether dialects of BASIC or entirely different languages like Python) to guarantee its survival.

What does, in my judgement, make BBC BASIC virtually unique - and thus deserving of a future - is the ease with which one can write programs which run on almost every major platform including running in a browser. That includes programs which involve 2D, 3D, and anti-aliased graphics, programs which use the GPU for super-fast rendering, programs which use the Box2D physics engine, programs using sound and music etc.

I don't know of any other programming language which makes it as simple to achieve that as BBC BASIC, not one! But of course it's BBCSDL, not BB4W, which has that enormous strength. Without BBCSDL, BBC BASIC is just one of a multitude of comparable Windows languages competing for the same market, and with no Unique Selling Point.

So you won't persuade me that BBC BASIC for Windows alone assures a future for BBC BASIC, it doesn't.

[Edja]

you won't persuade me that BBC BASIC for Windows alone assures a future for BBC BASIC

But I'm not trying to. I agree with all your arguments in favor of BBCSDL.

I've already told you that no such changes should be necessary!

As I said in my previous reply, I'll give it a try. I'm curious. The proof of the pudding will be in the eating.
Regards,
Edja

[JeremyNicoll]

Statements such as

Code: Select all

      SYS "LoadLibrary","OLE32.DLL" TO O%
      SYS "GetProcAddress",O%,"CoInitialize" TO `CoInitialize`
      SYS "GetProcAddress",O%,"CoUninitialize" TO `CoUninitialize`

and

Code: Select all

      SYS !(!O%+24),O%,F%,I%,`LCID%,T%,D%,U%,0,0 TO R%

make my head spin and this is just a sample...

I realise those are just examples, but the GetProcAddress lines are easy to understand. The Microsoft-supplied DLL is just a collection of functions or procedures that implement parts of COM. After you load a DLL into memory you only get told by Windows where in memory it placed the whole DLL. Each of those GetProcAddress lines finds a specific function or procedure's address within a loaded DLL, and saves it in a variable so you can later call that function or procedure.

To find out what the parameters passed to such calls are, you'd need to read some or all of the MS supplied documentation on what those functions / procedures do. Then the contents of comlib are a mixture of how one maps BB4W variables and data-structures onto what the MS code needs, plus any simplifications of the COM usage that Richard built-in to it. I would guess that looking at examples of the use of COMLIB would make what the BB4W functions/procs do slightly easier to understand.

In your second example, the SYS call, the O% there is a local variable in the function that that line came from, not necessarily the same thing as either of the two values that O% had in the code with the GetProcAddress calls (which - after all - loads two DLLs and stores each one's address in O%, very briefly).
RIght before that SYS statement in the code there's a comment:

REM IDispatch::Invoke(dispidMember,riid,lcid,wFlags,pdispparams,pvarResult,pexcepinfo,puArgErr)

So, Google for "IDispatch" and "Invoke" ... There's a corresponding list of parameters described at: https://en.wikipedia.org/wiki/IDispatch and within that page there's a link to the MSDN topic on what IDispatch is, from which one can find info on Invoke, at: https://learn.microsoft.com/en-gb/windo ... tch-invoke

None of that means much to me, because I know less about COM than you do... but if I wanted to find out how all this stuff works (which I'd remind you Richard says you probably don't need to know to use something similar in SDL) I'd spend a day reading around these MS documentation pages.

[Edja]

Richard, Jeremy,
So I've started to work on the "COMLIB migration to SDL"
As a first step I've written a barebone program, still in BB4W.
The reason to proceed this way is to start at least with a BB4W-debugged program, so that I will not become confused with other errors that will occur when I proceed with the modifications needed for BBCSDL

The program will start up Excel, open a file, then write a Boolean value, followed by writing a float number and a string. Then these last two values are re-read from the workbook.
The Excel file is then closed (data saved)
After cleanup of some garbage, the Excel application is also closed
This should suffice as a basic test to see if I can get COMLIB to work in BBCSDL.

The following step will be to make this run in BBCSDL (still figuring out how to, but I'll re-read your guidelines and the mail from Jeremy (thank you for your input))
Before running the program you'll need to create the Excel file as C:\TEST_SDL\Test_File.xlsx
At this stage I have no further questions, but if you would have any remarks/comments then they are always welcome.

Code: Select all

      INSTALL @lib$+"COMLIB"  PROC_cominit ON ERROR REPORT PROC_Report_Error:END
      Number=RND  Tekst$="The proof of the pudding..."
      Path$="C:\TEST_SDL\"     Test_File$=Path$+"Test_File.xlsx"

      Xap=FN_createobject("Excel.Application")

      REM Write a boolean to Excel // Will allow to display Excel messages
      PROC_putvalue(Xap,"DisplayAlerts(B TRUE)")
      PRINT "EXCEL has been started"

      Book=FN_getobject(Xap,"WorkBooks.Open("""+Test_File$+""")")
      Sheet=FN_getobject(Book,"WorkSheets(1)")

      REM Write a float to Excel
      PROC_putvalue(Sheet,"cells(5,2).value(F Number)")

      REM Write a string to Excel
      PROC_putvalue(Sheet,"cells(10,3).value("""+Tekst$+""")")

      REM Read a float from Excel
      PRINT FN_getvaluefloat(Sheet,"cells(5,2).value")

      REM Read a string from  Excel
      PRINT FN_getvaluestr(Sheet,"cells(10,3).value")

      REM Close the workBook and save the data
      PROC_callmethod(Book,"Close(B TRUE)")

      REM Release now obsolete objects
      PROC_releaseobject(Book)  Book =0
      PROC_releaseobject(Sheet) Sheet=0

      REM Close Excel...
      PRINT"EXCEL is being closed"
      PROC_callmethod(Xap,"Quit")
      REM ... and release now obsolete object
      PROC_releaseobject(Xap) Xap=0
      PRINT"EXCEL has been closed"
      PRINT"Data have been saved"
      PROC_comexit
      END
      *|------------------------------------------------------------------------------*|
      DEFPROC_CleanUp PRIVATE f:f+=1
      IF f>1 PRINT ' "Problems with PROC_CleanUp":PROC_comexit:END
      Xap+=0:Book+=0:Sheet+=0

      IF Sheet PROC_releaseobject(Sheet)             PROC_releaseobject(Sheet) Sheet=0
      IF Book  PROC_callmethod(Book,"Close(B TRUE)") PROC_releaseobject(Book)   Book=0
      IF Xap   PROC_callmethod(Xap,"Quit")           PROC_releaseobject(Xap)     Xap=0

      PROC_comexit
      PRINT'' "CleanUp done! Excel-Objects have been released"
      WAIT 100
      ENDPROC
      *|--------------------------------------------------------------------------*|
      DEFPROC_Report_Error LOCAL rapport$,message%,winerr%,oops$
      oops$          = "Oops! Error !!"
      DIM message% LOCAL 255
      REM  A Window error gives an error number>254
      IF ERR>254 THEN
        SYS"GetLastError" TO winerr%
        SYS"FormatMessage",&1000,0,winerr%,0,message%,255,0
        rapport$=$$message%
      ELSE
        rapport$=REPORT$
      ENDIF
      SYS"MessageBox",@hwnd%,rapport$,oops$,48
      PROC_CleanUp
      END