The future of 'BBC BASIC for Windows'

[Hated Moron]

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)

That's not exactly a simple example! Personally I'd be inclined to start with something less challenging, such as the SPEAK.BBC example program supplied with BB4W. That uses COMLIB, but demands a lot less of it than your proposed test.

Also I do not have Microsoft Office on my PC, it's far too expensive for the use I would make of it (which is basically none), so if you choose the Excel route and it doesn't work I wouldn't be able to help.

But ultimately it's up to you. You need to be comfortable with the program you try.

[JeremyNicoll]

Also I do not have Microsoft Office on my PC, it's far too expensive for the use I would make of it (which is basically none), so if you choose the Excel route and it doesn't work I wouldn't be able to help.

Nor I; I have LibreOffice, and only ever use it to view Word files sent to me. I've never originated a Word file or an Excel one... But maybe it's pssoble to control it via COM too? I found this page:

https://wiki.documentfoundation.org/Doc ... sional_UNO

where (at the top) item 4 seems to mention COM. Following some links from there it all gets very complicated very quickly. I did also find

https://api.libreoffice.org/examples/ex ... E_examples

where the second last set of exampled entitled "Object Linking and Embedding (OLE) examples" mention COM, and there's a VBS example where the function calls look vaguely like the things named in COMLIB.

I have to say I don't understand the difference between OLE and COM, so this may all be irrelevant.

Also within my copy of LibreOffice there is a DLL with an OLE-prefix name - oleautobridgelo.dll - but when I googled that name I didn't find much.

[Hated Moron]

the minimum size of a BBCSDL standalone executable is about 1.5 Mbytes. For demonstration purposes you can download just such a program here

As some of you should have realised (anybody paying attention, really) this was a teaser - it's well-known that BBCSDL cannot generate 'standalone Windows executables' in the conventional sense, because of its dependence on the SDL2, SDL2_ttf and SDL2_net DLLs.

In fact I'm rather disappointed that nobody picked up on it; were you not surprised? Did you download and run it to see if it was real? Did you wonder how it was achieved? If not it betrays a shocking lack of inquisitiveness!

Of course it was a cheat. What a close inspection will have revealed is that the file I linked to is actually a BB4W executable, but one which unpacks BBCSDL (along with the necessary DLLs) and runs it!

There's nothing wrong with considering BBC BASIC to be just a tool, a means to an end. I can't expect all users to be enthusiastic about it as well! But I hope some still are.

[Edja]

Richard,
I've checked for answers on "Differences between BB4W and BBCSDL" but couldn't find what I was looking for. So I've met a few hurdles :

Looking at the libraries to find examples of SYS calls in BBCSDL I see that in some cases you do this as in BB4W but in other cases you add the prefix SDL_ as shown in these two lines both from dlglib.bbc

Code: Select all

        SYS "GetClipboardData",1 TO H%
        SYS "SDL_GetClipboardText" TO t%%

Q1: Why/When to add this prefix (or not)?

The very first action that COMLIB executes is to load the OLE32 dll. I've added the prefix SDL_ to LoadLibrary :

Code: Select all

SYS "SDL_LoadLibrary","OLE32.DLL" TO O%

I've tried this also without the SDL_ prefix. In both cases I get the message "No such system call".
Q2: Do I need to look for another specific dll (compatible with the SDL layer) or is my SYS call flawed (probably)

...few 'essential' changes that I've previously outlined (adding the A suffix...

Less trivial (for me) then I anticipated. I couldn't find any examples in the libraries.
Q3 :Again, when/why do I need to add the A-suffix. Are there any examples in a library that I've missed?
Regards,
Eddy

[Hated Moron]

Looking at the libraries to find examples of SYS calls in BBCSDL I see that in some cases you do this as in BB4W but in other cases you add the prefix SDL

You're overthinking this. There's no difference in the way SYS is called in BB4W and BBCSDL. The reason you didn't find any mention of it in the differences document is that there isn't one!

Unlike Windows, SDL2 sensibly uses a uniform naming scheme whereby every function name starts with "SDL_", but you're unlikely to need to call any of those functions.

In both cases I get the message "No such system call".

I've mentioned it previously in this thread, but perhaps it would be helpful to reiterate the essential changes that you will always need to make when calling Windows API functions from BBCSDL:

1. If the Windows function has both an ANSI (A suffix) and a Unicode (W suffix) variant, you must explicitly add the A suffix in BBCSDL whereas doing so is optional in BB4W (although it will run faster if you do).
   
   
2. If the DLL containing the function is one which is loaded into the process automatically in BB4W (the list is here) but not in BBCSDL, you must explicitly load the library (SYS "LoadLibraryA") and extract the appropriate entry points (SYS "GetProcAddress").

The function LoadLibrary is affected by point 1. It has both ANSI and Unicode variants (see MSDN for confirmation) so in BBCSDL you must use SYS "LoadLibraryA".

If you particularly want to find an example in the existing programs supplied with BBCSDL, look at FNmalloc in SDLIDE.bbc.

[Hated Moron]

In both cases I get the message "No such system call".

If I may just add, honing your debugging skills would be of value. You could have searched all the programs supplied with BBCSDL for the string LoadLibrary (the supplied search utility means this would have taken only seconds). That would have immediately taken you to the line in SDLIDE.bbc which contains this function call, and you would have seen that it needs to be called as LoadLibraryA.

That way you would have found the solution without any need to ask here. With the current state of my brain (filled with fog and with a very poor memory) I am totally dependent on strategies like that to find answers and remind me of things that I have long forgotten. You would probably find them helpful too.

[Edja]

I've done the modifications inside COMLIB and changed LoadLibrary to LoadLibraryA in the 2 following lines

Code: Select all

SYS "LoadLibraryA","OLE32.DLL" TO O%

and

Code: Select all

SYS "LoadLibraryA","OLEAUT32.DLL" TO O%  

That seemed to do the trick. My test program, this time executed in the BBCSDL environment and with this ported COMLIB, runs correctly reading and writing strings and floats and writing a Boolean value to Excel, Open, Close and Save the Excel file and finally releases the obsolete objects.
It works exactly the same as with BB4W (the proof of the pudding !! ).
Unfortunately, on your side you cannot run the test program as you don't have Microsoft Office installed.

I'll now give this a rest for a day or so and then try to bring my production program to BBCSDL. Apart from COMLIB that one relies on the WINLIB, WINLIB2, WINLIB5, STRINGLIB, FNUSING, NOWAIT libraries. Some of these have not been ported yet so I'll have to do some more porting. We'll see ...

In hindsight this porting of COMLIB was extremely easy and proof of the quality of BBCSDL.
But I couldn't have done it without your advice. Thank you!!

Kind regards,
Eddy

[Hated Moron]

In hindsight this porting of COMLIB was extremely easy and proof of the quality of BBCSDL.

Not really, it just confirms what one would hope and expect: that running the same BASIC code in the same BASIC Interpreter on the same Operating System gives the same results.

In the early days of developing BB4W I was in two minds about whether to require the A suffix (for ANSI functions) in SYS calls or not. What swayed it was that the majority of the Windows API documentation of the day omitted the A, so I thought it would be confusing to require it.

But as you will have seen at MSDN, that has completely changed; now the API documentation does include the A suffix. Luckily, including it in BB4W is of course perfectly fine, and indeed will speed up execution slightly. So your new COMLIB should run without modification in BB4W.

Sadly I don't think there are any other Windows-specific libraries that will be as easy to port. Indeed in many cases there's no certainty that it will even be possible. I'm awaiting with interest feedback from DDRM and hellomike on their progress.

If you want a challenge (and it would be a big challenge) the next step for COMLIB would be to create a 64-bit-compatible library. It's in a completely different league of difficulty and not something I would be keen to attempt.

[JeremyNicoll]

If you want a challenge (and it would be a big challenge) the next step for COMLIB would be to create a 64-bit-compatible library. It's in a completely different league of difficulty and not something I would be keen to attempt.

Do you mean a library that would work on both 32-bit and 64-bit systems, or a separate 64-bit-only one?

What makes 64-bit tricky? - is it creating data structures with internal 64-bit pointers?

[Hated Moron]

Do you mean a library that would work on both 32-bit and 64-bit systems, or a separate 64-bit-only one?

It doesn't matter a great deal. A universal 32/64-bit library is more convenient, and all the other BBCSDL libraries are like that, but there's nothing desperately wrong with using code such as:

Code: Select all

      IF @platform% AND &40 INSTALL @lib$+"comlib64" ELSE INSTALL @lib$+"comlib32"

The 'compiler' will embed both versions in the application bundle, by default.

What makes 64-bit tricky? - is it creating data structures with internal 64-bit pointers?

There are the issues listed in the relevant section of the differences document plus COM-specific issues such as the way methods are called via their vTable entries, which would need adapting. I'm also not certain about the 64-bit COM ABI.

It's not necessarily that challenging if you're familiar with the internal workings of COM, but I'm guessing that not many people here are. Of course it's 'just' a case of consulting MSDN but, for reasons I've never understood, a lot of BBC BASIC programmers seem to have a mental block when it comes to converting descriptions in C-style syntax to BBC BASIC. It's a shame that the tool which used to be available to do this automatically no longer seems to be available.