The future of 'BBC BASIC for Windows'

[Hated Moron]

TL;DR; BBC BASIC for Windows needs you!

As everybody knows, I discourage the use of BBC BASIC for Windows for new projects, and I have actively reduced its prominence at the website. I encourage all new users to use BBC BASIC for SDL 2.0 in preference, for the very good reason that its future is much more assured.

The main reason for this, of course, is that BB4W is written in assembly language, is 32-bits only and is Closed Source. Once I am no longer able to maintain it - which is realistically a stage we have already reached, or very nearly - there will be no possibility of updating it. Should Microsoft make some change to Windows which impacts on BB4W, that will be it.

The worst-case scenario is that Microsoft drops support for 32-bit apps altogether. Windows is the only remaining major OS to support 32-bit applications fully. MacOS and iOS don't support them at all, Linux supports them but only by installing an optional extension which many users don't like to do, and some recent Android devices (e.g. from the Google Pixel range) won't run 32-bit apps.

Even in the case of Windows, the 32-bit version of the OS itself has now been discontinued, only 64-bit versions are available. So the writing is very much on the wall and it wouldn't surprise me at all if support for 32-bit apps is dropped fairly soon.

BBCSDL, on the other hand, is Open Source and written in C. This makes it much more amenable to being developed and maintained by any competent programmer. There are already 17 forks of the GitHub repository, which shows the degree of interest there has been. There's a 64-bit Windows edition of BBCSDL (although I don't make it available from the website).

The main reason for anybody wanting to use BBC BASIC for Windows is the support it provides for accessing the native Windows UI, allowing you to write applications which have the 'look and feel' of Windows. This capability is primarily encapsulated in the WINLIB* libraries. It also allows you to access other native API capabilities, such as you might need for multimedia applications, accessibility features and so on.

But if BB4W ceases to work or becomes unreliable, all is not lost. There is no fundamental reason why BBC BASIC for SDL 2.0 shouldn't access these same native features when running in Windows. After all it's a Windows app like any other, true it uses OpenGL rather than GDI32 for graphics and text, but that's not necessarily crucial.

What I'd like is for some volunteers (it's probably more than a one-man project) to do some experimentation to discover just how difficult or otherwise it is to make use of native Windows UI features in BBCSDL. Could one substantially reproduce the functionality of the WINLIB* libraries, but in BBCSDL rather than BB4W? What kinds of issues arise, and how can they be worked around?

I am well aware that the usual response to this kind of plea is apathy. Even if you've read this far, I can imagine you thinking "it's a good idea, but there's no way I can help". But if everybody thinks that way we're doomed. So please consider giving some of your time to this cause. I can't really contribute much myself, because my mental deterioration doesn't allow me to. But I can give encouragement and perhaps suggest ways forward if things are looking bleak.

[DDRM]

Hi Richard,

I'm not in the market until after my exams (June), but I might be prepared to help out with this after that.

I'm assuming that we have access to the Windows API vs SYS in the Windows version of BBCSDL? Or are you looking for a C implementation, for speed? Even the latter should be within my scope, though I haven't previously used DLLs from C, and most of my C/C++ experience is on Unix systems - but how hard can it be?

D

[Ric]

This might seem naive but I have encountered a problem.

No such system call

I can not be more precise, because the ide doesn't tell me where/what line in the program the call is made so I can not tell which call is referred to. There are many.

I would like to convert to SDL but, if the ide doesn't tell me where the fault is, most of my programs contain 1000s of lines and the process will be to slow to comprehend.

Is there a function I can turn on to help me locate errors?

Kind regards Ric

[Hated Moron]

I can not be more precise, because the ide doesn't tell me where/what line in the program the call is made so I can not tell which call is referred to.

What do you mean "the IDE doesn't tell you"? When debugging, the line where the error occurred should be highlighted in reverse video.

It's true, of course, that if the failure occurs in a library then there's no line to highlight, which is why libraries are assumed to be thoroughly tested and error-free. But in a situation when an error does occur in a library I use one of two simple techniques to discover where:

• Temporarily copy the library into memory after the end of the program (use File... Insert) so the line can be highlighted.
• Temporarily give the library line numbers, so the line resulting in the error can be identified that way.

Unfortunately SDL doesn't have tooltips, so the BB4W feature of displaying the error message if you hover over the highlighted line isn't available.

[Hated Moron]

I'm assuming that we have access to the Windows API vs SYS in the Windows version of BBCSDL? Or are you looking for a C implementation, for speed?

You know me well enough that I would never suggest coding anything in C! If you are talking about the BB4W WINLIB* libraries, they already use assembly language code to achieve what they do, and a BBCSDL version of those libraries would certainly need to do the same.

If one was lucky, the assembler code might need relatively few changes to run in BBCSDL (other than being converted from 32-bits to 64-bits if the maximum degree of future-proofing is attempted), but that's probably over-optimistic.

I would suggest that the very first thing to do, before running any code in BBCSDL, is to understand how the existing BB4W libraries work. That would be a pre-requisite for any attempt to port them, because if you don't know how the code works on one platform you're not going to have the slightest idea how to change it for another!

So, inevitably, you are going to need to know a fair bit about how the Windows UI works at the application level, and be able to understand x86 assembly language code. Nobody said this was going to be easy (if it was I might even have been tempted to give it a go myself).

[Hated Moron]

On 17/04/2023 09:27, svein svensson wrote (cross-posted from the Discussion Group):

> I'm assuming that we have access to the Windows API vs SYS in the Windows version of BBCSDL?
You did not not answer directly to this question.

BBCSDL provides access to the Windows API via SYS in exactly the same way that BB4W does. The only significant differences are:

• If there are both ANSI and Unicode versions of the function, you must specify the ANSI version. So for example SYS "SendMessageA" works, but SYS "SendMessage" doesn't.
  
  
• The pre-loaded DLLs are not the same. There will be ones common to both (I would expect them to include KERNEL32.DLL and USER32.DLL) but not all BB4W DLLs will be available in BBCSDL without being loaded explicitly.

But I would expect the majority of common Windows API functions to be callable without any code changes at all.

Code: Select all

SYS "SendMessage", @hwnd%, &500, 0, 0

Does not and/or will not work whereas:

Code: Select all

push 0
push 0
push &500
push @hwnd%
call "SendMessage"

will work ?

It makes no difference at all whether you use the SYS statement or assembly language, the available API functions are the same. So in this case you would need to use "SendMessageA" in both cases.

Please note that in BBCSDL @hwnd% isn't the native Window handle, to get that from SDL2 you must use SYS "SDL_GetWindowWMInfo". That's generally true of course, for example @memhdc% isn't a Device Context in BBCSDL (despite its name).

[hellomike]

Is it an idea to create a new forum group dedicated to migrating from BB4W to BBCSDL?

I have questions and during migrating certainly new ones will arise. It will be a valuable source (group) and in my opinion making it easier to start or consider starting, migrating all (my) BBC4W code to BBCSDL.

I'm reluctant to ask additional questions in this thread because it will grow very large and eventually it will be hard to see what answer is meant for what questions.

Just a thought.

Have a nice day.

Mike

[Hated Moron]

Is it an idea to create a new forum group dedicated to migrating from BB4W to BBCSDL?

I'm reluctant to ask additional questions in this thread because it will grow very large and eventually it will be hard to see what answer is meant for what questions.

Just a thought.

It looks like the forum's administrator (DDRM) hasn't responded to this - he is the only person able to add a new section. So I don't know whether he thinks it's a good idea or not.

I would support some forum reorganisation, because there's still an 'Advent Challenges' section from 2021 which could usefully be removed - there were no additional challenges in 2022 as far as I recall.

Meanwhile please don't be concerned about posting to this thread, it hasn't exactly been overwhelmed so far! I expect there will be issues that arise in respect of 'migrating' the WINLIB* libraries to BBCSDL (if it proves possible at all) that I can help with.

One misunderstanding has already arisen. Because the differences document states that "In BB4W the SYS statement accesses the Windows API, in BBCSDL the SYS statement accesses the SDL 2.0 API" this has been interpreted as meaning that you can't call the Windows API from BBCSDL.

But that's not true. The reason the document says what it does is, of course, that if you are writing a program to run on multiple platforms - which is the main point of BBCSDL - the only API functions that you can safely call are SDL 2.0 API functions.

But when BBCSDL is running in Windows you can call a subset of Win32 API functions, to be precise those in the DLLs which SDL 2.0 loads. The only caveat is that you must specify the full function name, including the A (ANSI) or W (Unicode) suffix if appropriate.

However to be on the safe side it probably would be wise not to rely on this capability and to load the required Windows DLL(s) - using SDL_LoadObject() - and acquire the function address(es) - using SDL_LoadFunction() - which should always work.

[DDRM]

Hi All,

I didn't respond, because in the context of this conversation I assumed it referred to setting up a different forum - and given my lack of expertise in BBC-SDL I wouldn't be a sensible admin for such a forum.

If we want another section here, I can look at setting that up: where do you think it most logically goes? In the "environment" section, next to the "interpreters and runtime engines"? Or in "general", next to "BBC BASIC Language"? Or do you think it needs a whole new section of its own?

WRT to the Advent challenges, yes, I can hide/delete that: I tend to regard the forum as a reference site/archive as well as a "conversation" site, so I tend to leave existing material alone, in case people want to refer back to it. I think the Advent challenges are still interesting programming challenges, even if they DO have a bit of a seasonal theme... Happy to take them down - and perhaps a more active curation might help deal with the download bandwidth issues when someone comes in and tries to download the whole site. Richard, drop me a PM or email if you think this is a useful way to go, and we can discuss what to ditch / hide.

Best wishes,

D

[Hated Moron]

I tend to regard the forum as a reference site/archive as well as a "conversation" site, so I tend to leave existing material alone

I'm not suggesting for a moment that you delete any existing "material", but having a dedicated sub-forum for such a specific category as Advent Challenges seems a bit bizarre. There should be quite a high bar to creating a new sub-forum, and I'm not at all sure that this reaches it. Where would it end: Advent Challenges, Easter Challenges, Summer Challenges, Miscellaneous Challenges?!

You could probably justify a sub-forum with a broader description such as 'Challenges'; there have been a number of previous challenges which could go there as well as the Advent ones, and there's a reasonable likelihood of new ones being created.

But doesn't this all rather pale into insignificance considering that the continued existence of this forum is very much in doubt? Svein has failed in his attempts to move it elsewhere, despite huge efforts, and he says it's not even possible to restore if from a backup, which strikes me as a massive problem that you ought to be very concerned about.

I would suggest that your top priority ought to be to liaise with Svein in order firstly to resolve the backup/restore problem and then, once that's sorted, use it to move the forum to his new host.