RiscOS/BBC - TCP/IP

Hello Forum,

What (LIB) is recommended for BBC-Basic IP workers ???

I would like using at least the following protocols in BBC-Basic/RiscOS:

+ FTP
+ HTTP
+ IMAP
+ IPPort
+ LDAP
+ MCast
+ MIME
+ MX
+ Ping
+ POP
+ RCP
+ SMTP
+ Whois
+ XMLp
+ UDP
+ Telnet
+ SSL
…

SSL? In BASIC?

Provided you know how the protocol works, you can directly implement it using the socket SWIs. Many years ago I wrote a POP3 fetcher in BASIC. Then I rewrote it in C.

SSL is not so important .. just the standard TCP/IP protocols would be enough for me – and maybe a micro HTTP/FTP-server – Is there a LIB most people are using ?… i am in RiscOS/BBC just a few days … so excuse me, if this is a very redundant question.
I wouldnt like to start with socket programming .. somehow i am sure there is a standard lib, isnt it ?

thanks

Is there a LIB most people are using ?… i am in RiscOS/BBC just a few days …

Ah, I see the problem. Generally, RISC OS does not have libraries. Some exist, but it isn’t anything to match the library/framework system you may have seen on other platforms.
Instead, many facilities are offered via Modules which are somewhat like DLLs in Windows.

For using sockets and Internet communications, take a look at http://www.riscos.com/support/developers/prm/internet.html

For C, we have the structs and functions described. For BASIC, you may have to roll your own and call SWIs directly.

Looking at some (two?) decade old code, it’ll be something like this:

SYS "Socket_Creat", 2, 1, 0 TO handle%
buff%!0 = 2 OR ((port% DIV 256) << 16) OR ((port% MOD 256) << 24)
buff%!4 = ip%
buff%!8 = 0
buff%!12= 0
SYS "XSocket_Connect", handle%, buff%, 16, 0 TO ; flag%
SYS "Socket_Ioctl", handle%, &8004667E, 1
$(buff%) = "GET "+what$+" HTTP/1.0"+CHR$(10)+CHR$(0)
SYS "Socket_Write", handle%, buff%, LEN($buff%)
$(buff%) = "Host: "+who$+CHR$(10)+CHR$(10)+CHR$(0)
SYS "Socket_Write", handle%, buff%, LEN($buff%)
[...]

Now, three things of importance that you know:

Firstly, BASIC is a closed environment. The BASIC interpreter executes BASIC programs, and it can also assemble and execute assembler – but if it does so directly, it does so within the confines of the BASIC “world”. What I am getting at is that the OS provides a variety of potentially useful behaviours such as event handling, callbacks, service calls, etc. Using these with BASIC ranges from extremely tricky to impossible; the exact level depending on how well you know assembler and the low level mechanisms of the BASIC interpreter.

Secondly, RISC OS manages multitasking by using task switching, and this is implemented by paging out the current task (removing it from the logical memory map) and paging in the replacement task in its place. Every application believes that it begins at address &8000. For BASIC programs, it is a little higher due to BASIC claiming some workspace – usually around &8F00 (PRINT ~PAGE will tell you). I say this because if you manage to get events (etc) working, or you decide to use C where it is a little bit simpler, things will get really unpleasant if you are paged out and the OS tries to call you. It will jump into whatever is at the given address (could be tokenised BASIC code, could be a sprite…) and, in general, expect crashiness to ensue. (such things are best handled as modules, which are written in either C or assembler and (importantly) don’t get paged out so won’t risk missing events)

Thirdly, to save you figuring out how to resolve an IP address in BASIC (the indirection is hairy), here is some skeleton code from my very-old program. In true Internet tradition, this is copied manually from the monitor on the right (RISC OS) to this machine (a PC) and is completely untested. ;-)

DEFFNresolve_address(domain$)
  REM domain$ should be the domain parsed out of the URL, like
  REM "www.heyrick.co.uk" or "www.argonet.co.uk".
  REPEAT
    SYS "XResolver_GetHost", domain$ TO stat%, rb% ; flags%
    IF (flags% AND 1) THEN
      REM Something went badly wrong, deal with it then get out of here.
      =0
    ENDIF

    REM Call your Wimp polling routine here, so the machine can
    REM carry on multitasking while the domain is being looked up.

  UNTIL (stat% <> 36) : REM EINPROGRESS
  IF (rb% = 0) THEN
    REM Unable to look up address.
    =0
  ENDIF

  REM Hairy code to extract IP address from the address block.
=!(!(rb%!16))

and maybe a micro HTTP/FTP-server

http://www.cp15.org/webjames/ – I’m running it on my Pi. It has a fair few features and it seems reliable, though the only hammering it gets are the caprices of Chinese ’bots.

I wouldnt like to start with socket programming .. somehow i am sure there is a standard lib, isnt it ?

If we’re talking about C, then yes. There is TCPIPLib in the official DDE. I would imagine GCC offers something similar. Generally, the “lib” is just a nice C-friendly wrapper for the SWIs, so it is a fairly straightforward conversion from C call to SWI (for use with BASIC).

Or did you mean higher level like:

ip = lookup_host(domain);
handle = connect_to_server(ip, port);
send_to_server(handle, "blah");

If so, I don’t think that exists. Maybe in GCC? It is something I would like to have the time to add to (my port of) DeskLib. Of course, absolutely none of that would be any use to you if you are using BASIC…

Mark: don’t let Rick put you off. You can write a sockets application perfectly well in BASIC without any of the complications he listed. (I have written some, so I’m speaking from experience.) The complications only become relevant if you need to get fastest speed.

You will certainly need the internet.html link – there is a huge amount of information there, along with some examples. The difficulty when you’re using BASIC is that the examples are in C, and, to make use of any of the calls, you’ll have to dig through the header files in TCPIPLibs.h and populate some memory areas to mimic the C structs required by the calls. So you’re going to need some basic knowledge of C anyway.

It does take some time, determination, and trial and error to make something work. If you structure your code well, you should be able to re-use significant parts in further apps.

Good luck and happy coding!

You can write a sockets application perfectly well in BASIC without any of the complications he listed.

;-)

(I have written some, so I’m speaking from experience.)

As have I. The reason I listed those “complications” was to try to pre-empt the “Oh, there’s an Internet Event” followed by “Oh, it all blew up!”. You and me: We know RISC OS. We know the strengths and limitations. We know the BASIC environment and what it can and cannot do.
These are not things we can assume that a person new to the platform would know. Doesn’t it seem reasonable to write a function and get the OS to just call it endlessly, say, twice a second? RISC OS can do this. BASIC, not so much.

You will certainly need the internet.html link – there is a huge amount of information there,

Mmm, I refer to it myself. Also the StrongHelp Sockets manual is good to have around, moreso that it allows easy switching between the SWI call and the associated TCPIPLib function.

If you structure your code well, you should be able to re-use significant parts in further apps.

Certainly – you only need to write the “resolve name to IP address” code once…

Good luck and happy coding!

And remember – you can ask us stuff. ;-)

The reason I listed those “complications” was to try to pre-empt the “Oh, there’s an Internet Event” followed by “Oh, it all blew up!”.

He doesn’t need to handle an Internet Event.

ok .. thanks for your advices

It might be better “coding” in C then ?

honestly I am not so sure about it, because what I really like with the RiscOS-concept is the possibility booting your own piece of code on PI from SD with RiscOS/PICO – this actually is my TARGET here . .. but from my understanding till now this just is possible with BBC-BASIC.

If this also is possible with C, i maybe would switch to C… or any other recommended language.
Or maybe just writing “modules” in C.

DLLs in Windows can be developed in any language … and f.e. can be used with Visual Studio
Is the same possible with “modules” ? … maybe this is the way to go here ?

If so, what are you recommending for compiling C-code/modules in RiscOS ?

What i also like with BBC-BASIC is, that i can run it under Windows.. coding with a common editor I am used to is quite comfortable then.
My TARGET actually would be, going on like this – and maybe experienced RiscOS developers are able recommending me the perfect environmental – or pointing me to a few links, which are necessary enhancing my coding output.

What I also need is PI-Hardware access.. particulary USB and Pi-Cam.

thanks so far

DLLs in Windows can be developed in any language … and f.e. can be used with Visual Studio Is the same possible with “modules” ? … maybe this is the way to go here ?

Modules must either be hand-written in assembler (perhaps using the one built into to BBC BASIC), or compiled from a supported high-level language such as C. You can’t write modules in BASIC, because they’re effectively low-level parts of the system (BBC BASIC itself is implemented by a module, for example).

What i also like with BBC-BASIC is, that i can run it under Windows.. coding with a common editor I am used to is quite comfortable then.

ARM BBC BASIC isn’t the same beast as BB4W, if that’s what you’re thinking… They’re similar, but there are some significant syntactic and functionality differences, and the files are not binary compatible as the two versions use their own tokenisation schemes. Transferring files between the two isn’t impossible; it’s just not completely simple either.

The underlying OS is different, too — as soon as you start to use SYS in your code, there’s no portability. Any BB4W library to do networking will almost certainly be calling SYS.

It might be better “coding” in C then ?

You can probably do what you want in BASIC; personally, I’m not sure that’s a good justification for trying it, though.

If so, what are you recommending for compiling C-code/modules in RiscOS ?

You have two options: the Desktop Development Environment, or DDE (the C compiler of which is usually known as “Norcroft”), and GCC. The former costs money; the latter is free, but has an (unwarranted, IMO) reputation for being difficult to set up and use. The DDE is the one used to build RISC OS itself.

> ARM BBC BASIC isn’t the same beast as BB4W, if that’s what you’re thinking…

hmmh ..yes, I actually was thinking this – at least on a high level, graphical functions, GUIdesign etc.

so what i want to do are the following simple mobile applications:

+ reading data from Pi USB Ports, f.e UMTS, WLAN
+ accessing an internet http/ftp-server, sending/reading data via ftp
+ using pop/email for accessing an emailserver
+ using MIPI, Pi/CAM
+ using USB in general
+ accessing GPIO
+ designing a low level GUI, which is booting with RiscOS/PICO
etc.

then booting my piece of code with RiscOS/Pico from SD using RasPI as a very thin client and mobile device with different SD-Cards (accessing my emails, accessing datas on the web, sending camshots to a http/ftp-server etc etc.)

is this all possible with BBC BASIC ? .. and are you recommending developing all under RiscOS/PI ? .. or do you think its possible using BBC/WIN ?

The biggest benifice i see with RiscOS is, booting extremly thin clients from SD with RiscOS/PICO. This actually is my target here.. yes

It might be better “coding” in C then ?

But it’s also possible to do it in Basic :)

Transferring files between the two isn’t impossible; it’s just not completely simple either.

Except for code that calls external libraries or uses some specific syntax, compatibility between the two is really great.
It’s sometimes easier to make something that will work on both BBC Basic and BBCB4Win than to make something that will work unchanged on BBC Basic and ABC.

The underlying OS is different, too — as soon as you start to use SYS in your code, there’s no portability. Any BB4W library to do networking will almost certainly be calling SYS.

Completely true, even if it would be possible to make libraries that will provide the same APIs on both systems.
Anyway, even big BBC Basic projects can be very portable: http://www.svrsig.org.uk/software/SigBoxRisc.htm

is this all possible with BBC BASIC ? .. and are you recommending developing all under RiscOS/PI ? .. or do you think its possible using BBC/WIN ?

It’s possible under RISC OS, even if you’ll need to dig inside SWI and other things, as the set of advanced Basic libraries is really small.
Your contribution here would be very welcomed.

It’s also possible on Windows, especially for the client part. Of course, code will be different from the server/object side, but to have the same tools on both sides is really great. C is another option, but not really better. Yes, you have it on both sides, but yes, there are syntax differences between the two too, and yes, libraries are not the same on the two OS too. BBC Basic is old, but it’s not a bad solution.

I expect to set up a library of code for BBC Basic (RISC OS, Windows, portable, 8bit) with the launch of the next edition of BBC Basic contest. More details soon.

I converted a multi-tasking application programme running under RISC OS BASIC to run under BBC BASIC for Windows and it wasn’t exactly straightforward. See here for some of the differences I had to make.

True for a desktop application. But it’ll be the same (or even worst) with C.
The point is probably here not to make a port, but to have the object part on a Pi and the desktop part on a PC. The use of the same language is a plus here.

Of course, some people will say that you should not care, and that you can use two different languages. The same guys that will tell you later to use C on both sides, because the use of the same language is a plus. Hum…

IMHO, BBC Basic is less modern than Python, but very capable. And fast too. It just lacks more (portable) libraries.

True for a desktop application. But it’ll be the same (or even worst) with C.

Probably not. C is much easier to modularise than BASIC (it isn’t as good as higher level languages, but it’s better than nothing), so writing an application where the GUI and functional stuff are separate is fairly simple. Think NetSurf for an extreme example…

The use of the same language is a plus here.

Sadly, BBC BASIC for Windows and ARM BASIC are not really the same language. Superficially they are, but if you don’t make use of the additional features of BB4W when working in that dialect, you’re doing it wrong – and doing so soon makes for a different program structure.

Chris:

See here for some of the differences I had to make.

Wow. That’s practically a different language. ;-)

Do you have to maintain two versions or is there some way of selecting which bit of code to use on the fly?

David:

Generally my advice would be to use the language you feel most comfortable with. BASIC is limited in some respects, but married with assembler it can be extremely capable. Full big applications have been written like that (PhotoDesk, for instance), as well as some games (Chocks a Away). Fair enough, the heavy lifting is passed to assembler code, but it can be done. If you feel more at home with this arrangement, then go for it.
Personally, I prefer C. It is more modular, code can be assembled into reusable libraries, and being a compiled language even the mundane parts are fast. But C is not for everybody. The standard library calls have a definite feel of “we threw this together one night while chilling out to Tubular Bells” (look at the placement of the file pointer in stdio.h calls), the standard library is clever in some ways (sscanf) but retarded in others (no cross platform way to list items in a directory), there is nothing that even remotely resembles bounds checking (forty years later we are still paying the price of buffer overruns), there is no such thing as a string, it is just an array of bytes with a convention saying it should end with a NULL byte (though beware, strncpy will NOT terminate a string when it clips it. And don’t even get started with the horrible Eldritch Abominations that pass as valid pointers.
On the other hand, it is possible to single-step through a C program line by line examining total program state¹ should the need arise.²

“You”³ have options. Pick what works for you.

David, a specific note. I got burned quite hard by a command line C program under RISC OS that used int extensively, and recompiling the same code using Borland TurboC++ where int != long and arrays are all different inside, and anything even remotely system specific was very very different. To a degree POSIX has brought some standardisation to this, but at the cost of expecting everything to look and feel like Unix. So while it is completely valid to say C is C and code is portable, the reality of it is something different. It is possible to build a RISC OS and a Windows program largely from the same (or mostly the same) sources – witness OvationPro; however I think the only way that would be less than traumatic is to plan it that way from the outset…

¹ Though I suspect most people would drop in print statements, spit some data to a log file, etc. It is bound to be less hassle than using DDT.

² I am actually surprised that Acorn never ever put together an “execution environment” for tracing BASIC code; perhaps as an extension to ARMBE. BASIC’s debugging support is…not the greatest.

³ Third party “you”, referring to everybody reading.

no cross platform way to list items in a directory

Not surprising. Some platforms may not have directories (rember Pick?) and some may not even have filing systems – a washing machine, for example. But if by platform you want to include both Unix and RISC OS there could be difficulties. The standard Lua distribution has no way to list directories – nothing that is not in ANSI C. But of course there are platform-dependent libraries that add this facility. RiscLua has it built in, and in a slightly unusual way compared with other scripting languages, as an iterator

for leaf, ftype in riscos.dir (here) do ... end

is there an SMTP-Server like Sendmail ?

is there an SMTP-Server like Sendmail ?

Do you mean a server for RISC OS? Dave H might say what issues he run into. I have installed a cross-platform mail server called Xmail on my Linux laptop and I can send and receive emails seamlessly from RISC OS.
It will be seriously tested at the end of the month when I lose my home internet connection.
Xmail uses virtual users/mailbox’s, and requires no other programs for send/retrieve or smtp/pop from local machines. On the face of it, it should port to RISC OS, but I think network server programs are trickier than client programs.
I ported Privoxy to RISC OS but it doesn’t let other machines connect to it to use the proxy,
It works fine on the local RISC OS machine though.

Apologies in advance to bring a large elephant into this room, but what the original poster really needs is a 32-bit version of Easysockets. Easysockets was a RiscOS relocatable module that provided a much simplified interface to the RiscOS socket programming SWI/SYS calls written by a gifted programmer called Justin Fletcher. I have successfully used the Easysockets module to write a Usenet (NNTP) reader in Basic that, sorted threads automatically by poster names (hence concentrating on ‘good’ threads with good posters and ‘binning’ all the trolls).

Unfortunately, Justin has let it be known that he does not want a 32-bit version of Easysockets to be distributed, and we respect his wishes. Note that I have read somewhere that under EU law ? an individual may modify the 26-bit Easysockets module themselves to make is 32-bit compliant for their own use ONLY. They CANNOT distribute the 32-bit version.

Whatever, forget Justin’s easysockets module as this is really a dead end, apart from showing what is possible. What we need is an enterprising C (or assembler) programmer (Rick?) to write and release a new 32-bit ‘clean room’ version of a module with similar functionality to Easysockets. We could call it BasicSockets32 or similar :-)

How about it ?

Ralph

edit: corrected Jason to Justin (I blame my sub-conscious – its got a mind of its own;-)

But C is not for everybody.

That’s the point. I’m for ‘programming for everyone’. And BBC basic is not so bad for this.

Note that for games or simple software BBC Basic and BBC Basic 4 Win are PERFECTLY compatible. I drop code from one to the other almost every day without any problem.

Of course, BBC Basic 4 Win has some new features. As BBC Basic with Basalt. But roots are common. Even for simple sound and graphics (try this in C).

We could call it BasicSockets32 or similar :-)
How about it ?

Module or a set of BBC Basic libraries.
I agree. More libs are needed.
And a better ABC too :) Will pay for this.

We could call it BasicSockets32 or similar :-)

If it was me, I’d just call it “EasySockets (not Justin’s one)” and provide a compatible API. That way it ought to function as a drop in replacement.

The EU directive you are thinking about is probably the interoperability clause in the copyright gumph. Though personal copies are not a lot of good if nobody can distribute them. ..

 forget Jason’s easysockets module as this is really a dead end

Jason Justin. ;-)

In any normal situation, I’d try talking nicely to Justin as enough time has passed that we (on both sides) really ought to start looking at ways to move onward together as opposed to two warring factions. Certainly the older hardware is only getting older and there has been nothing from the other branch in years. We really ought to get some ROLtd users on board so we can offer them upgrade options when they may need it. RO5 has a long way to go before it can match the things Select offered, but we can at least start together, can’t we?

Now read this (warning NSFW, not child friendly): https://groups.google.com/forum/m/#!topic/comp.sys.acorn.apps/2dCAm0Bq5aM

I think we can all understand Justin’s reaction. Some person (and believe me, I’m using stronger words in my head) took things to the point where continuing was simply not worth it. I don’t agree with Justin’s decision not to make 32 bit software, but it isn’t exactly surprising given his involvement with the 26 bit OS. But that response in that message. Great. Thanks a lot. movspclr is no longer, and with it one of the most knowledgeable people RISC OS has known has departed.

We really ought to get some ROLtd users on board so we can offer them upgrade options when they may need it.

I think you will find they are already here, just not shouting from the rooftops.
Yes, some would rather stick pins in their dangly bits than associate with the RO5 branch but those are a minority. Some just want to see something they consider worth the change.

Note that I have read somewhere that under EU law ? an individual may modify the 26-bit Easysockets module themselves to make is 32-bit compliant for their own use ONLY.

Which is a shame on two counts

1. Lot’s of useful stuff from Justin will just fade away quietly in a corner
2. At a quick glance EasySockets doesn’t have anything much beyond function exit code that needs changing in order to be useful.

I don’t agree with Justin’s decision not to make 32 bit software, but it isn’t exactly surprising given his involvement with the 26 bit OS.

While I don’t like it, I totally understand his reaction.

Note the abuse wasn’t just public forums: http://web.archive.org/web/20030410200908/http://www.movspclr.co.uk/diary/index.html
see Feb 9th

My response?

“…”

Sometimes there is just nothing one can say.

Chris:

See here for some of the differences I had to make.

Wow. That’s practically a different language. ;-)

Do you have to maintain two versions or is there some way of selecting which bit of code to use on the fly?

Fortunately the rest of the programme is almost the same on both platforms and, by the time I did the Windows version, the Acorn version was pretty mature. The data for each are exactly the same (the Windows version does a draw file render item by item just like the Acorn version).

> EASY SOCKET

Yes Ralph .. you are very right
I dont want to begin with Socketprogramming again

Win10 IoT could be released soon .. and if they are coming behind, that PICO .. or a Pi/Win32 MicroSubSet (Powershell) is the secret to be successful in the embedded market, then RiscOS will be history again.
Better hurry up .. and port Easy Socket to BBC ;o)