ROOL C compiler

I need a little help with working the ROOL C compiler, and I was wondering where the best place to go for help. newsgroup? mailing list? forum?
It’s a fairly trivial one, how do I know what to put in the library path if I use the GUI to compile and link an object.

From what I can see the answer is don’t bother, use a Makefile, as the header files contain info that is correct for that – but seem wrong for the GUI.

Generally where to RISC OS programmers “hang-out”.
I figure I’ll probably wait a few months before hastling people though, learn through pain is always better!

I expect you’re not getting many replies because a lot of the people here use Makefiles or the command line. The DDE GUI is, however, the closest thing RISC OS has to an IDE, and I know IDEs are a very popular way to program on most other platforms.

The answer to your question is “it depends what you’re trying to do” because you’re looking at it from the wrong angle. The process should go

• decide if you want to use a library for part of your program
• evaluate the available libraries, and choose the one that suits your needs best
• write code that talks to that library’s API
• configure the link step, including telling the linker where you have installed the library that you want to use

The manuals (printed or PDF) that were included with your DDE do a reasonably thorough job of describing how to use the GUI tools – I wonder if you spotted them?

I think a good question to ask is what does is meant by library path? The % (*Lib) or some sort of library?

Really, everything, when correctly “seen” by the filer, will have set stuff up so the executables (cc, link, etc) are within Run$Path (so just work), and other paths for library code, so you can:
link -aif -o @.!RunImage @.o.code C:o.stubs DeskLib:o.DeskLib32
or whatever.

However, as Ben says, a MakeFile is nicer as I can tweak code in !Zap, then do Ctrl-Shift-C and the file will be saved and the MakeFile started, so it’s an even simpler build process than making a VB app under Windows!

Malcolm, investigate MakeFiles (the examples?). It makes stuff much simpler. Ignore if you get a warning saying something like “MakeFile incorrect, removing project”. I get that all the time, it’s a pretty bogus error…

I think I’m just too old school! my idea of an IDE is !Zap or in linux vi
I thought it would be easier to use the GUI…I should have learned by now, I’ve tried netbeans, eclipse etc. in the past and they are impossible to use for me.
The Makefiles make perfect sense, are easy to use and follow logic in the c header files. Guess I’m used to being “under the hood” rather than polishing the bonnet.

I didn’t notice the Manuals as I just installed the Compiler and was too excited getting into programming to notice other things that didn’t install that were on the USB stick! Glad I’ve found them though.
Can you get hard copies of the PRMS, or is it a case of printing them off?
I used to love my old copies, shame I’ve lost ’em!

Generally where do RISC OS programmers “hang-out”? I figure I’ll probably wait a few months before hastling people though, learn through pain is always better!

It used to be the case that every programmer was on the comp.sys.acorn.programmer newsgroup. That’s probably where you will still find the widest range of help including many real experts who know vast amounts about the operating system.
These forums are pretty good, so don’t be afraid of asking here, but you’ll probably reach a wider audience on the newsgroup.

There’s also the GCC mailing list, but that’s more relevant if you’re using GCC or porting Unix stuff!

Can you get hard copies of the PRMS, or is it a case of printing them off?

Try CJE Micros: they may have them in stock if you are lucky. Otherwise EBay maybe? The PRM CD has them in HTML and PDF form, but I still use hard copy mainly. The StrongHelp OS manuals are well worth getting. They can be a bit sparse in detail, and occasionally wrong, but Alt-Double-Click on a SWI name in Zap to bring up the page is such a time-saver.
There is a recetntly published new edition of PRM3 (or at least the part which covers the Window Manager) published by RISC OS Limited to cover the changes in the RISC OS Select fork of the system, but to be honest, that won’t help much as you would forever be having to work out what couldn’t be used in RISC OS 5.

CJE Show them as being in stock and brand new!!
http://cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=ACO-AKJ03

I think I’m just too old school! my idea of an IDE is !Zap or in linux vi
I thought it would be easier to use the GUI…I should have learned by now, I’ve tried netbeans, eclipse etc. in the past and they are impossible to use for me.

Code colourisation is a help, as is auto-indent/outdent, but I’m in two minds as to what I think about automatic variable completion. I think I would like to find it a useful feature, it is just that VB’s one is a little bit… strange at times.

I think, however, the trend is to try to move away from lower level stuff. I have an IDE on my mobile phone (yes, a complete Android Java-like compiler!) and while the setup is an unholy mess of files in folders, most of this is ultimately hidden once the project has been set up. Like a MakeFile, only moreso. And yes, it will offer to finish variables for me.

Perhaps coming from an assembler background, I prefer a more hands-on approach? I have never in my life written a “class”, and I fail to see how object oriented is doing anything you can’t do with normal code. It was a fairly easy transition from a linear program to an event-driven (Wimp) program, but then it is a lot like interrupt code – you just wait for something to happen then deal with it.

I agree that hardcopy PRMs are the better option. There’s something satisfying about a pile of “docs” weighing down your lap. Plus the ability to stick in lots of PostIt™s! That’s not to say PDFs don’t have their uses, I just prefer paper. Sadly my (small) attempts to get the DM3730 printed (all 3600+ pages) resulted in a silly price (I could buy a cheap laser and run off my own copies for less).

Excellent find! CJE have one less copy now :-D
Reading through PDF’s is a nightmare, especially if it’s long.
I’m currently working on a project with an 800 page PDF to read, boy do your eyes strain! Worst of all the PDF is updated each weekend, I am not looking forward to the new one on Monday!

:D I agree, you can’t beat a set of printed manuals!

I’ve totally given up on the ROOL compiler, for me it seems totally broken.
It’s given me errors such as #include file <sys/socket.h> wouldn’t open, that’s just plain wrong.
For now I’m going to develop on linux, and probably use the GCC compiler on RISC OS when I get it completed.

Quite depressing, I switched to Linux and it compiled and ran perfectly first time….

The compiler takes the point of view that if it’s not in the ISO C standard, you must explicitly enable it. One of the reasons for this is that, unlike operating systems like Linux, RISC OS does not (with the exception of !Boot) impose a fixed directory layout upon the user.

<sys/socket.h> isn’t an ISO header file, it’s part of the BSD socket library – which just happens to be used on most operating systems, RISC OS included. If you have set up the RISC OS build environment (and possibly !SetPaths in the DDE also? – I don’t remember, as I hardly ever use it) then you will find the TCPIPLibs: path has been set up to make it easy to locate the copy of this library that they contain.

To use this path, use -ITCPIPLibs: to tell the compiler where to find the header files, and when linking, link with library files TCPIPLibs:o.socklib5, TCPIPLibs:o.inetlib and TCPIPLibs:o.unixlib. (These are referred to by the symbol ${NET5LIBS} for convenience if you are using the shared makefiles from the RISC OS build environment.)

Yes… you have to remember that RISC OS Isn’t Unix, and so Unix functionality is not as integral as it is on, well, Unix. So it needs intentionally enabling.

There’s another library called Unixlib that provides lots of Unix functionality if you want that (it’s not the same as TCPIPLibs:o.unixlib which is a much smaller subset). If you use GCC that’s included by default, but you can switch it to the RISC OS way of doing things with the flag -mlibscl (to use RISC OS’ Shared C Library) instead. You can also use this UnixLib with the ROOL C compiler if you wish.

I think for the moment i need to concentrate on getting things working. There is clearly going to be a learning curve getting used to the RISC OS way of doing things again.
Once I get the socket parts done and dusted I need to write the WIMP part of the application and plug that into it, so I think that’s going to be a far more appropriate time to start feeling the pain.
At least then it’s constructive pain, at the moment it’s just learning a different way of doing things to start writing a test framework, which is likely not to work smoothly anyway – I think too much pain all at once! From what I’ve seen from going through the RISC OS header files, all the libraries and functions I need are identical to UNIX – so porting across the libraries should be easy, as I’m doing all of the complex processing in ANSI C standards, it’s only the tcp/ip comms using non ANSI C.

I found all the stuff about TCPIPLibs and the linking in the libraries, I initally tried to use the GUI to do it and gave up.
Then I managed to get it to compile using a makefile, then it all broke again, for “no reason” (clearly there was a reason, and it was my fault.) I lost the will to live at this point.
The old circles of immense frustration and then excitement, now I remember why I became a sysadmin from a C programmer. At least I understand why people smash keyboards, throw mice across the room and punch monitors.

Once done I should probably write an idiots guide to converting from UNIX C to RISC OS, it’s realistically not difficult (as anything in programming) it’s just knowing what’s going on and why.

Malcolm, I’m not suggesting that this is something you look at now (especially as I haven’t released a Raspberry Pi (read RISC OS 5.19/ARM V7) friendly version yet) but when the time comes to look at the WIMP side of things you might want to take a look at Sourcery. The intention of this is to try and remove some of the pain. You may not find it your cup of tea. Some people do, some don’t.

To be honest I’ve have similar problems with gcc with heavy use, it drives me mad going through all of the compile and link options and debugging massive make files by hand is “less than fun”.
Thanks Richard, I’ve taken a quick look on the website. Looks like a great tool, again not sure if I’ll like it or hate it either! But anything that stops me losing my part of my life looking at idiotic compile options and linker options is a winner in my book.

One other thing… if Unix is your background you might be interested in the GCC cross compiler, which is GCCSDK. I do most of my developing in Linux these days and simply cross-compile for RISC OS. If you have a project with a simple makefile, you just run ‘$GCCSDK_ENV/ro-make’ instead of ‘make’ and everything gets built for RISC OS instead of for Linux. That saves some of the mucking around with filenames and pathnames etc as you can use just the same Makefiles that Linux does. Unix libraries can be built completely unmodified. If the project uses autoconf or other build systems those can be coped with too.

It’s not ‘raw’ RISC OS, but if you don’t use any ported libraries (eg gtk) then the output is pretty much the same as the native tools.

Once done I should probably write an idiots guide to converting from UNIX C to RISC OS, it’s realistically not difficult (as anything in programming) it’s just knowing what’s going on and why.

Watch out! You talk about socket code, then you talk about Wimp. You will discover that because RISC OS uses co-operative multitasking, things have to be done a tad differently (you can’t just write a chunk of code to do something and rely upon the OS to page it out from time to time, you must explicitly yield, which means you can’t just use blocking calls).

It isn’t so hard, but it isn’t a straight port of something from the Unix world.

Rick: I started coding properly on RISC OS, so I am aware of how I need to code things, and I always use non-blocking code in sockets and slow I/O calls anyway, it’s the standard way IMHO of doing socket code – otherwise you can end up in a world of pain, pre-emptive or co-operative tasking doesn’t really matter. co-operative means you just need to write very very solid code and think a little more.
I was going to write it as main as the theoreticall wimp poll section.
The main issue I have is some of the calls are different names, socketread rather than plain read and socketioctl rather than just ioctl. There near enough the same though. But I need the expat library now, I finished the socket coding. So I’m going to go into path pain and get expat compiled and working, that’s gcc code but I should be able to link with it using the ROOL compiler I think???

Richard: I managed to get sourcery working on my Pi no problems :-D so I’ll have a look at it, OLESupport had me wondering – but I’ve got Messenger PRO and that has that module, installing the toolbox was fairly easy as well.

Wish me luck!

co-operative means you just need to write very very solid code and think a little more.

I rather wish this was standard practice.
Back circa Y2K I was involved in a lot of discussion calling RISC OS a “toy OS” because writing to null pointers crashed the OS and how it is the job of the OS to protect against stuff like that.
Thing is, modern (non-toy!) OSs do a little too much protection, which has encouraged people to write lazy code, that along with one of the most common languages having zero default bounds checking… well, it leads to ElReg headlines talking about how hundreds/thousands/millions got pwned by a password breach.
Maybe if those coders grew up with a machine where bad code would cause bad side effects, they’d think a little more carefully about how stuff is implemented…

Wow! As far as I remember the reason that RISC OS crashes and other OS’es don’t is simply down to the fact that to use swap files you have to have memory protection – it wasn’t a design feature of the “modern” OS.
This is a case of programmers thinking they know everything.
Another classic is memory leaks in java are impossible.
Programmers may know programming well, but they usually know nothing at all about how an OS and the underlying hardware works.

Whilst swap is great for server software, I find it has only contributed to massive bloat and lack of care.
Firefox is a classic example of this, I switched from Mozilla to Firefox 0.1 because it was lean. Now look at it!
And they call things optimising now, where what they mean is a complete rewrite of code that was complete garbage to begin with.
This isn’t what I was brought up to know what it meant.

As far as I remember the reason that RISC OS crashes and other OS’es don’t is simply down to the fact that to use swap files you have to have memory protection

Memory protection helps a lot, but it isn’t entirely necessary for running a virtual memory system. You just need to be able to trap accesses to non-existant addresses and toss them to the OS to jiggle stuff around. Actually protecting who can access what is a bonus.
Look at Windows 3.1x – its memory protection was abysmal (remember the General Protection Failure?). It was still pretty lame in Win32 (95, 98, ME) but a lot better. Finally nailed down decently as of XP.

This is a case of programmers thinking they know everything.

Like hell they do. There’s little justification for the sort of ridiculous wastes of resources that we have nowadays. I accept that a web browser will have a lot of data associated, and that it may be quicker to be wasteful for video decoding (like expanding a bitfield to atomic words, so simple loads and stores can be used to read/write them, a hell of a lot faster than bit ops); but surely I ought to be able to run a browser and a video player on a 1Gb machine without something falling over?

Another classic is memory leaks in java are impossible.

Indeed, ClassLoader seems built to cause interesting memory leaks. Likewise, have a thread create a bunch of child threads, then release the parent thread. Suddenly all the children have vanished. Oops, bang!

This, of course, is not even looking at the potential of bugs/errors in the JVM itself.

but they usually know nothing at all about how an OS

This is one of the benefits of RISC OS. It is small enough that, while one person may struggle to understand every piece of code, it is certainly feasible to understand the operation of the entire OS and how it all fits together and interacts.

and the underlying hardware works.

This is why I would support bringing the BBC Micro back into schools. I know it is crappy and old, but look at the Beagle or the RPi. That little chip you are staring at? That’s not the processor. No, the processor is hidden underneath and for what it is worth, with I/O and GPUs and such, the “processor” itself is only a small part of the silicon.
How are you supposed to understand that?
There is a lot in assembler programming that is tied to the architecture. At least with a Beeb you can get dirty, to the level of working out where every clock pulse goes, every logic line, and – for example – to map out the state of the entire machine at every single cycle in the initial boot code. Such a thing just isn’t possible with modern devices. You can sort of cheat with JTAG, but even so with the memory controller and CPU on the same piece of silicon, large chunks of its internal operation are hidden from you, and may not even be described in the datasheet (as it isn’t something you can access, therefore…).

I may be wrong, but I believe that it is simply not possible to write good code without having an understanding of how the underlying hardware operates.

Whilst swap is great for server software,

Not really. Swap loads response times as every time it is used something needs to be stuck on disc and something else retrieved.
Swap was introduced because fairly powerful operating systems (yes, even Win3 on a low-end AT clone) needed to run on mediocre hardware, and back when harddiscs were a shocking price but memory was even more ridiculous. It is still the case that memory carries restrictions – a lot of low/middle systems won’t accept more than 4Gb RAM as those sorts of modules will set you back money that could buy you a terabyte harddisc. So in essence, for the benefit of economy, you are trading speed for capacity. Unfortunately as harddiscs get bigger and bigger, it is a near limitless capacity.

Firefox is a classic example of this, [snip] Now look at it!

My eeePC has no VM due to using solid state SSD storage. I had to bump up the onboard from 1Gb to 2Gb so I could load Firefox and other stuff at the same time! I’m stuck with Firefox 3.6.x for the time being (even though I notice Flickr, Google Maps, and Google Groups no longer work – I wonder if there is something in the scripting that is designed to be incompatible with older browsers?) because I’m uncertain if upgrading to FF12 would be a step forward, or backward. I’m still wondering what the hell is going on that we went from v3.6 to v12 in such a short length of time.

This isn’t what I was brought up to know what it meant.

I’m not the world’s best coder, but I look at some of the stuff floating around now and I find it genuinely scary to think that it might be kicking around important systems. A lift that ran on relays and 74LS series logic chips might have been simple but it wasn’t going to go tits up for no specific reason. A lift running an operating system? That’s more concerning, especially when you look at the fancy display of a out-of-order lift and you see Windows booting, blue-screening, and booting again, over and over and over, as if maybe one of these times it might actually work. Suddenly I feel fat and out of shape and with a desire to take the stairs…

As regards my swap comment, it’s usefull on servers so you don’t get OOM killer (out of memory kernel process that kills hungry processes, usually the ones you don’t want to be killed) if something goes arwy, also so you can dump the panics to it. Agreed using swap will cause pain!
And you need 1Gb of VRAM as well so the GPU can accelerate the web browser, because rendering text is really CPU intensive…..
Running firefox on RISC OS, isn’t a good idea at the moment – given it’s memory usage and CPU usage I would think pre-emptive is an essential for the latest versions.
I’d be happier to do a monthly donation to netsurf and at the moment I’d consider a decent one too.

Well, I think giving up and coming back to my problem was the best thing I did.
Ramadan over, and 15 minutes of looking at it had the makefile working and program compiled!
But now I definately think I have an alergy to IDE’s, makefile way was so much easier to understand and think out.