Acorn's C Libraries
M Y Ben Gershon
[Much stuff about rewriting Acorn's RiscOSLib deleted]
Well, some of us are talking about the possibility of porting gcc to Risc OS.
Now release 2 of gcc (GNU c), which is about to go to beta testing, will
have an ARM code 'backend'. If this will port over to RiscOS, possibly with
the help of UnixLib, then it would open up C++ and Objective C to Archimedes
users.
A C++ window class library for RiscOS would, IMHO, be the best solution to
all of the RiscOSLib shortcomings.
Michael
TMOTA
# I have had it up to HERE (points to a spot 3 miles above his head) with
# Acorn's C Libraries as supplied with Desktop C.
#
# I have just found that Acorn's menu functions position menus in the correct
# y-position for an iconbar-menu UNLESS they have dotted lines in them, in which
# case they are WRONG! This is a very elementary calculation.
#--- End of flame. Read on... ---
Before you think "Here comes another HUGE flame from t-mota-mouth" (see, John
I can insult me too!) here is what I suggest:
Why don't we get a group of people together from the net, to each write a\
small portion of the functionality of a complete library?
I am willing to write replacements for (e.g.) Acorn's shocking "dbox"
functions, but the only way I could use them properly would be to either
integrate them with Acorn's library (Thanks for not making "extern" all the
internal library "hook" functions and variables, acorn) or write the entire
library again...
Perhaps we could even convince some of the people at Acorn to donate some bits
of the real source code... I mean the terrible fault in the menu code that
I mention above could be fixed in about 5-10 minutes if I could get my hands
on the source code...
Some improvements I can suggest (just to give you an idea of why new libs are
needed) would be:
A STANDARD nomenclature:
no more wimp_open_wind(), wimp_GetWindowOutline(), etc.
NICE, MEMORABLE names for data structures
-Hands up all of you who thought "m" was a menu? WRONG!
In this context "m" is a mouse structure. Intuitive, huh?
GENERIC (i.e. works for aplications OTHER than Draw & Edit's use of them)
functions. i.e. menu functions that ALWAYS get the menu in the right place
dialogues that can
a) Be "brought up" and left on-screen indefinitely ("tool windows")
b) be brought up with more than ONE dialogue at once
c) routines that supply a fully-automated save-as window which will allow
you to do something rebellious like use 3-d or indirected-sprite icons
d) MULTI-BLOODY-TASKING error boxes
e) being able to get NULL events passed to a specific window (e.g. a
dialogue) without your "main event loop" having to "know" about it.
etc. etc.
(Guess who's already had to re-write most of the dbox functions himself? ;-)
not to mention...
NO BUGS!
(or at least, if bugs existed in it, YOU would have the sources for the buggy
code, so YOU could fix the problem immediately instead of sending a report to
Acorn and waiting 2 years for RISC OS 4.00)
So what do the netters think?
Do we storm Acorn's archives and get our hands on their C Library code
(50% of which is excellent, and 50% of which is missing/buggy/etc)?
or do we cooperate to write a new, improved, public domain, sources-
included-so-you-can-fix-problems-and-see-how-to-do-dinky-things-
yourself and totally wonderful set of libraries?
And what do the guys'n'gals at Acorn have to say? Any chance (ha!) of us
getting our hands on the C Library sources so that we can MAKE THEM WORK?
(please?!)
PLEASE SAY "YES"!
(Jeremy Lee: I know you are busy with your ray- er... fract- er... sound...er
WHAT was it you were writing again?!? so you needn't apply if you think that
your part of the code might be delayed by other coding commitments ;-)
--
_________________
/____ _ _/_ __ The Master of the Arcane jw...@cs.aukuni.ac.nz
// / //_//_ /_/ Smileys ;-) indicate humorous or sarcastic remarks
Jeremy Lee
>(Jeremy Lee: I know you are busy with your ray- er... fract- er... sound...er
>WHAT was it you were writing again?!? so you needn't apply if you think that
>your part of the code might be delayed by other coding commitments ;-)
>
>--
> _________________
> /____ _ _/_ __ The Master of the Arcane jw...@cs.aukuni.ac.nz
> // / //_//_ /_/ Smileys ;-) indicate humorous or sarcastic remarks
Well, first of all I'm not that good a C programmer (although
I'm gonna have to get pretty good at C++ by the end of semester. ;-)
so I don't think I'll be replacing anyones C code for a while.
Second, Yup, I am pretty busy with my sound program. And
that Neural network Visualiser I have to write for COMP325/2, oh, and
there's that bloody Expert System I have to write before friday, and
(Oh joy, oh frolicking joy!) I have that course on UNIX that I've gotta
pay attention too.
Plus there's about 20 things I have thought of over the past
week that I'd love to do, but KNOW for a FACT that I never will. I
forget over half the things I think of (Thank God!) and I am DETERMINED
to get this sound program (Tentativly called !Rhythm) done before
anything else. All this talk about shareware has put me off the
idea of trying to sell it that way. I'll finish it, and probably
just give it away. I can't really be bothered to try to sell it ;-)
ps. Good to see you back!
Jeremy Lee - Never short of Ideas, Never Enough time.
"Ideas for sale, Ideas for sale!!"
***********************************************************************
* . Jeremy Lee s0...@sand.sics.bu.oz.au Student of Everything *
* /| "Where the naked spotless intelect is without *
* /_| center or circumference. Look to the light, *
* / |rchimedes Leland, look to the light" - Dale Cooper *
***********************************************************************
David Alan Gilbert
> Use UnixLib as a base (it's a full ANSI library). Write a WIMP
>library that runs on top of it to complement it. The filename conversion
>stuff will be made 100% RiscOS compliant in the next release of UnixLib,
>and the use of an environment variable by vfork()/execve() will be replaced
>by a coded command line arg: these two are the only problems with using
>UnixLib as a complete replacement to Clib. UnixLib is also faster
>than Clib at things like division, printf(), etc. (MUCH faster printf()).
>It's also smaller, more tightly coded, and full source code comes with it.
>Executables generated do not need the Clib module, and code bloat is
>very limited 'cause UnixLib is finely grained...
Why not build this Wimp library on UnixLib compiled under the ARM version
of gcc (OK the beta version) and then write the wimp library in c++ - isnt
that what c++ is supposed to be good at?
So a complete set, equivalent to the Acorn package would be GNU gcc version 2,
UnixLib (compiled under gcc), and the Wimp library ( a name is needed for this!).
Except this would have the advantages that :-
1) The full source would be there
2) It would be free.
3) It would probably be faster than the Acorn code (the printf in Huw's UnixLib
is considerably faster than the Acorn one - I dont know what the rest of the
library is like).
4) It would make porting existing Unix stuff really easy.
>-Huw
Dave
--
-------------------------------------------------------------------------------
- David Alan Gilbert - gilb...@p4.cs.man.ac.uk - G7FHJ@GB7NWP -
-------------------------------------------------------------------------------
rogersh
I am nearing completion of a fullscreen Mode 13 paint package.
It has all of the standard features, but is designed to be used by graphics
artists engaged in software development (mainly games, demos, and other
graphically oriented programs using square pixel 256 color modes). It
allows you to manipulate files of sprites very easily (like !Paint), but
is massively better from the graphics point of view, providing amongst
other features an undo function, bezier curves, innumerable coloration
techniques, different plot modes, and a plinthed UI with key shortcuts.
If anyone has any suggestions for features I'd like to hear from
you. Many suggestions will have already been incorporated, but I'd like
to know about people's gripes with existing packages and any new features
people feel they need.
Thanks,
-Huw
[ H.J.Rogers INTERNET: rogersh%p...@cs.man.ac.uk ]
[ ,_, JANET: rogersh%p...@uk.ac.man.cs ]
[ :-(_)-o "I'll be back..." ]
[ _} {_ "Computer Science is an engineering discipline." ]
rogersh
>Why don't we get a group of people together from the net, to each write a\
>small portion of the functionality of a complete library?
>
UnixLib is pretty bug free...
>
>(or at least, if bugs existed in it, YOU would have the sources for the buggy
>code, so YOU could fix the problem immediately instead of sending a report to
>Acorn and waiting 2 years for RISC OS 4.00)
>
>So what do the netters think?
> Do we storm Acorn's archives and get our hands on their C Library code
> (50% of which is excellent, and 50% of which is missing/buggy/etc)?
> or do we cooperate to write a new, improved, public domain, sources-
> included-so-you-can-fix-problems-and-see-how-to-do-dinky-things-
> yourself and totally wonderful set of libraries?
Use UnixLib as a base (it's a full ANSI library). Write a WIMP
library that runs on top of it to complement it. The filename conversion
stuff will be made 100% RiscOS compliant in the next release of UnixLib,
and the use of an environment variable by vfork()/execve() will be replaced
by a coded command line arg: these two are the only problems with using
UnixLib as a complete replacement to Clib. UnixLib is also faster
than Clib at things like division, printf(), etc. (MUCH faster printf()).
It's also smaller, more tightly coded, and full source code comes with it.
Executables generated do not need the Clib module, and code bloat is
very limited 'cause UnixLib is finely grained...
Of course this is a bit of self advertising! ;-)
GI WEST
articles about an Arc verson of GNU C. Is this available yet? If not, how
long with it be before it is available? What is this UnixLib thing I've seen
mentioned as well?
I've used C a little on Unix, and I'd like to get into using it, but so far
I've been put off buying Acorn's versions as they seem to produce very large
executables and some people have mentioned bugs in the libraries.
If there is the possibility of getting C++ on the Arc as well via gcc then
I'm really interested in getting hold of the GNU program.
Graham
James
> [stuff deleted]
>
>I've used C a little on Unix, and I'd like to get into using it, but so far
>I've been put off buying Acorn's versions as they seem to produce very large
>executables and some people have mentioned bugs in the libraries.
>
> [stuff deleted]
I wish people would stop making comments like 'there are bugs in Acorn C
Libraries'. The RISC OS libraries are split into two different sections :-
1. RISC_OSLib
2. CLib
The CLib are the standard C function libraries (stdio, stdlib etc..) and are
of a reasonable quality (I would say 'bug-free' but I don't beleive that any
software can claim it).
The Library that people seem to be complaining about is RISC_OSLib, which is
our own interface to RISC OS (ie: the window manager etc...). Even though
this library may have a few bugs, it is still perfectly usable. I have been
programming with RISC_OSLib for many years now and have never had any real
problems with it, even when giving it a heavy bashing. Lots of our
internal software is written with RISC_OSLib and one hell of alot of third
party software is also constructed with it.
If it is so bad then why do so many people use it?
Desktop C is a reasonably high quality product and I would not be put off
buying because of a few bugs that people keep griping about. Remember, the
person who started this subject appears to spend most of his time slagging
off Acorn anyway.
--James
James Bye
Acorn Computers Ltd
"The views expressed are thought to be my own but my
machine is known to type things without my knowledge!"
P. Chown
It's not available yet, and functions for driving the Wimp probably
will not be available for some time.
>I've been put off buying Acorn's versions as they seem to produce very large
>executables and some people have mentioned bugs in the libraries.
The executables are not too large, about 2k for hello world, and about
50k for a 4000-line program with the Wimp support included. Both
these figures are after the object files have been compressed, at run
time they decompress to about twice the quoted sizes.
>If there is the possibility of getting C++ on the Arc as well via gcc then
>I'm really interested in getting hold of the GNU program.
C++ will be available as part of the GNU package, when it appears.
I'm interested as well!!
--
======================================================
Pete Chown, email pc...@phx.cam.ac.uk (Internet) ||
or pc...@uk.ac.cam.phx (Janet :-) ====
Ug!
> ...If anyone has any suggestions for features I'd like to hear from
> you.
Does that mean you're almost a Roger, but not quite?
Anyway, here's an idea. At the moment, we're involved in a whole bunch on
animation, and what we've got is a graphic artist (a *real* one!) doing the
initial full-colour drawings which are then scanned.
However, they don't draw every frame, since it's easier to make minor
modifications on the computer itself. So an art package which could take two
disjoint pictures, and make some sort of stab at morphing from one to the other
(in the specified number of additional frames) would be useful. Of course, the
frames would have to be tidied up manually, but at least it would be a start.
Ug!
P.S. Why limit it to mode-13? I'll be doing most of my work in modes 12 and
20, with some work in modes 15 and 21.
Pete Goodwin
In article <12...@acorn.co.uk>, jb...@acorn.co.uk (James) writes...
>The CLib are the standard C function libraries (stdio, stdlib etc..) and are
>of a reasonable quality (I would say 'bug-free' but I don't beleive that any
>software can claim it).
I'd agree CLib is fairly robust, though in ANSI-C Release 3, signal didn't
behave as it should.
>The Library that people seem to be complaining about is RISC_OSLib, which is
>our own interface to RISC OS (ie: the window manager etc...). Even though
>this library may have a few bugs, it is still perfectly usable. I have been
>programming with RISC_OSLib for many years now and have never had any real
>problems with it, even when giving it a heavy bashing. Lots of our
>internal software is written with RISC_OSLib and one hell of alot of third
>party software is also constructed with it.
>
>If it is so bad then why do so many people use it?
I think part of my problem is the documentation. I've only just found out that
dialog boxes fall to pieces if you use an icon that is write/click/drag. Change
to writeable and everything is hunky dory.
As for overall, the RISC_OSlib seems to me to be fairly robust. It's taken me a
year to get to grips with it, but I seem to be getting things going as I want.
The documentation around the draw routines is lacking in examples. I wrote my
own routines before I realised what the RISC_OSLib routines were about.
>Desktop C is a reasonably high quality product and I would not be put off
>buying because of a few bugs that people keep griping about. Remember, the
>person who started this subject appears to spend most of his time slagging
>off Acorn anyway.
I agree, with the exception of !Make. I've reported bugs on it. I don't use it
because it has some serious limitations, it crashes too often for my liking.
!Amu has been better, but I think there's something amiss with TaskWindows
because I've often seen a build finish but the window says 'running'. Trying to
abort hangs the machine. I think I've reported this bug too.
In summary, I was surprised about the discussion about RISC_OSlib. It's not
THAT bad! I just wish the documentation sometimes would give more examples.
BTW, I'm referring to ANSI C Release 4.
Pete Goodwin
goo...@system.enet.dec.com
G.I....@bradford.ac.uk
and about the GNU compilers.
Thanks to all that have provided me with info.
I think I shall probably buy Desktop C. It all depends when I can get the
money together...
Graham
I J Palmer
>
>Desktop C is a reasonably high quality product and I would not be put off
>buying because of a few bugs that people keep griping about. Remember, the
>person who started this subject appears to spend most of his time slagging
>off Acorn anyway.
>
>--James
>
>James Bye
>Acorn Computers Ltd
>
>"The views expressed are thought to be my own but my
> machine is known to type things without my knowledge!"
Personally it's the price that's stopping me buying Desktop C, at the
moment I can not afford over #200 (after just forking out #1500 for an
A5000 :-)) Another thing that's stopping me buying it is the fact that
I feel narked, to say the least, with Acorn at the moment - and also I
seem to remember that Desktop C costs around #70 to the rest of the
world (well almost) and so I do not feal like subsadizing others at my
own expence at the moment..... Are Acorn going to bring down the price
of Desktop C to come in line with what those in New Zealand have to
pay???? (I think that's where it was).
And anyone at Acorn, if your listening, CAN I HAVE MY DISC BACK
PREFERABLY THIS YEAR (last year would have been nice)
Now to the real purpose of my posting, U have a dire need to expand
the memory on my new A5000, but I am not sure which of the many boards
to chose from (there seem to be oh so many) - I was wondering if
anyone had sugestions as to the quality of the various available
boards. I am considering the Atomwide 2M board, but I have had no
dealings with them before and know nothing about their quality
(I shall NOT be considering the Beebug board as I know about their
quality).
I would be grateful for any information about any of the upgrades that
exapand the A5000 memory to 4M (or above)....
Ian
--
| Ian Palmer e-mail : i...@doc.ic.ac.uk | Crossword clue : | PANIC NOW |
|---------------------------------------| 1200 (10,7,4) | and avoid |
| Dept. of Computing, Imperial College, |---------------------| the rush. |
| 180 Queens Gate, London SW7 2BZ, U.K. | This space for rent |-----------|
David Alan Gilbert
>In article <1992Feb5.1...@bradford.ac.uk> G.I....@bradford.ac.uk (GI WEST) writes:
Stuff deleted
>The Library that people seem to be complaining about is RISC_OSLib, which is
>our own interface to RISC OS (ie: the window manager etc...). Even though
>this library may have a few bugs, it is still perfectly usable. I have been
>programming with RISC_OSLib for many years now and have never had any real
>problems with it, even when giving it a heavy bashing. Lots of our
>internal software is written with RISC_OSLib and one hell of alot of third
>party software is also constructed with it.
Ahh....But is your software written with the release RISC_OSLib or
versions you get correct before releasing the software?
>If it is so bad then why do so many people use it?
They dont - they use C 3.00 when they hit a serious bug in V4.00 library!
I am looking at a program to modify now which I may have to use V3.00 for,
because the V4.00 library just doesnt work - I reported the particular bug
over 3 months ago - and others have had a moan about the same bug on the net!
>Desktop C is a reasonably high quality product and I would not be put off
>buying because of a few bugs that people keep griping about. Remember, the
>person who started this subject appears to spend most of his time slagging
>off Acorn anyway.
Please define 'a few bugs' - I have reported in the region of 20 - mainly
minor bugs, but some serious - I must admit I have received help with
some of them - but if I reported 20 how many has everybody else reported?
>--James
Jeremy Lee
*PLEASE* Don't invent your own, wonderfully non-standard
file format for saving te screens. Everyone else does and it's annoying.
Undo? Wonderfull. Does it work from the desktop? It better. In
any case you had better be able to get back there when you need to. It
might be nice if you just displayed the image in a window and allowed
a few rudimentary operations (Load, save) when on the desktop. Clicking
in the window could make it full screen. You could also implement
multiple editable files at once, having them all in their own seperate
windows on the desktop and clicking in any one would drop into full-
screen mode to edit it. I do admit that I would like the choice of
being able to edit in both full-screen and desktop modes, as both would
be handy at different times. In any case you had better be able to get
back to the desktop. The machine *is* multitasking y'know.
If you are going to put in fuction key shortcuts, make sure
of two things. Function key equivelants are re-defineable, and every
function can be assigned a shortcut. You don't know what people will
want to do most often. And, you can supply a few different key templates
so that users of !Paint will be familiar, users of that Amoeba program
(what's it called again? ;-) will be happy, and (god bless 'em) !Impression
users will be happy too. (You can hear them screaming "All I want is
for shift F3 to *save*")
Forget handling anything but sprites. There are plenty of
programs about that do translations. OK, put in a few translators
if you want ;-) Actually, you may want to handle the three big ones,
GIF, TIFF and JPEG. It's secondary and won't necessarily help the program.
Give us LOTS of shading options! I want huge amounts of graduated,
dithered, radiating fills with user-definable colour gradients with
sensible interpolation. That brings me onto the next point...
No matter what sort of pallete scheme you adopt, someone will
hate it, so give them a choice. Everything from RGB to HYV to crominance-
luminance to a rainbow pallete. Also, be the first to allow for re-
definition of the pallete in 256 colour modes. There are plenty of
ways that the pallete can be changed in 256 colour modes for more
subtle variations, by sacrificing a colour here for a colour there.
I don't know how to do it, but I'm sure you can think of some ways.
For gradiated fills or magic brushes or selectable colour
ranges, can you please get the computer to do interpolations for
us? It is annoyin to want to go from green to white and having to
pick every colour in between. The computer is much better at it.
There are huge numbers of tricky effects that can be
put in the package. Wrapping pics around spheres, oblates, streched
planes, volume-rotated curves etc. Transparency is pretty important,
and a lot of funny things can be done with 256 colour masks.
Grab a few graphics books and code every weird effect they
describe, because someone, somewhere, will like it.
Allow the output of colour-separations for graphics work.
Put in functions for tiles for games, by splitting the screen
in to 8x8 or 16x16 or... size tiles.
*FATBITS* is a MUST!!!
I would be great to work with several documents in memory at
once, to be able to cut/copy/past between them.
That's all for now...
Clive Jones
>
> I am nearing completion of a fullscreen Mode 13 paint package.
> If anyone has any suggestions for features I'd like to hear from
>you. Many suggestions will have already been incorporated, but I'd like
>to know about people's gripes with existing packages and any new features
>people feel they need.
You just have to be aware of what Atelier can do, and be careful to make your
offering perform better. Atelier has oodles of painting modes, such as washes,
shading, tinting, it has distortions, sprite manipulation, pixelisation,
beziers - all that stuff. What is lacks is multiple-document editing, running
in a desktop window (you click the icon on the icon bar - it takes over the
screen, rather like the new PC Emulator), and adequate handling of large
numbers of fonts.
If you manage to combine the user interface of !Paint, and all its facilities,
with the extra facilities offered by !Atelier, then I'll be interested.
--Clive.
P. Chown
>Desktop C is a reasonably high quality product and I would not be put off
>buying because of a few bugs that people keep griping about. Remember, the
>person who started this subject appears to spend most of his time slagging
>off Acorn anyway.
Time I put my pennyworth in...
Yes, the language parts of Desktop C are reasonably good - the
compiler is the best C compiler I have used, the ANSI library is
perfectly adequate. RISC_OSLib, yes, well it has a few bugs but by
and large it does its job.
But FrontEnd and the other things that interface to the Desktop are so
*NAFF* it is unbelievable. On the first day I had Desktop C I managed
to crash the FrontEnd (repeatably), so I then wrote my own replacement
for it that so far seems pretty crash-proof. The other problem is
that FrontEnd puts loads of stuff in the RMA so when you find yourself
with 1.5M RMA allocated you'll know why! My replacement does it the
sensible way - it doesn't store all the output programs generate in
the RMA, it bounces it back to another Desktop application, so when
you've finished with the text it can be thrown away and memory
reclaimed.
The !Make utility supplied with the package seems to be some sort of
joke. I can write a makefile in about a fifth the time it takes to
shove everything through !Make. And, if I write my own makefile I am
not constrained by all the silly restrictions about the number of
commands that can be run in any one make step, etc. And, I can move
my programs around the disc without the maker throwing a wobbly.
Sorry this is rather on the flaming side, but if people are going to
accuse us of griping about trivial bugs they are rather asking for it...
Tony Veijalainen
s0...@SAND.SICS.BU.OZ.AU (Jeremy Lee) writes:
....
>(what's it called again? ;-) will be happy, and (god bless 'em)
> !Impression users will be happy too. (You can hear them
> screaming "All I want is for shift F3 to *save*")
....
> No matter what sort of pallete scheme you adopt, someone will >hate it, so
give them a choice. Everything from RGB to HYV to crominance-
>luminance to a rainbow pallete.
How about making a replacement to awfull Palette-task module and
selling/licensing it also to others. Or make the Impression to offer
palette selection through Impulse ( of course you probably would have
to persuade CC to make it available through it's impulse server. I just
bought a cheque for them to send to finally uppgrade to Impression 2.x )
--
Tony Veijalainen e-Mail: Tony.Vei...@helsinki.fi (preferred)
c/o CARP-Finland ry
PL 164 phone: not know yet new number, for couple of weeks
00171 HELSINKI +358-0-349 6205 (mornings)
James
>Personally it's the price that's stopping me buying Desktop C, at the
>moment I can not afford over #200 (after just forking out #1500 for an
>A5000 :-)) Another thing that's stopping me buying it is the fact that
>I feel narked, to say the least, with Acorn at the moment - and also I
>seem to remember that Desktop C costs around #70 to the rest of the
>world (well almost) and so I do not feal like subsadizing others at my
>own expence at the moment..... Are Acorn going to bring down the price
>of Desktop C to come in line with what those in New Zealand have to
>pay???? (I think that's where it was).
>
I think you will find that 200 quid is relatively cheap for a complete
compiler environment. Surely someone with great programming expertise will
soon be able to make up for it by writing some decent software :-)
The C Complier is classed as a 'serious' piece of software and most software
of this nature will cost you in the range #150 - #200.
--James
James Bye
Acorn Computers Ltd
"...... and may the skin of your arse never cover a banjo!"
James Bye
Acorn Computers Ltd
"...... and may the skin of your arse never cover a banjo!"
Pete Goodwin
>I think you will find that 200 quid is relatively cheap for a complete
>compiler environment. Surely someone with great programming expertise will
>soon be able to make up for it by writing some decent software :-)
>
>The C Complier is classed as a 'serious' piece of software and most software
>of this nature will cost you in the range #150 - #200.
I'd agree up to a point... it's just that some of the tools supplied with
desktop C aren't perfect. !Make is one, and TaskWindow is another.
I do like desktop C - it's made a big difference in writing software. The
debugger has made looking for bugs a lot easier - I just wish it would look
after it's use of RMA better (or RMA tidy up better).
Pete Goodwin
goo...@system.enet.dec.com
TMOTA
to date...), but I just couldn't let this one past with out a reply...
Sorry if this is very old or it was thrashed to death in the messages I
haven't yet read...
In <12...@acorn.co.uk> jb...@acorn.co.uk (James) writes:
>I wish people would stop making comments like 'there are bugs in Acorn C
>Libraries'. The RISC OS libraries are split into two different sections :-
> 1. RISC_OSLib
> 2. CLib
>The CLib are the standard C function libraries (stdio, stdlib etc..) and are
>of a reasonable quality (I would say 'bug-free' but I don't beleive that any
>software can claim it).
Yes, CLib seems to be pretty good... It's RISC_OSLib that isn't.
>The Library that people seem to be complaining about is RISC_OSLib, which is
>our own interface to RISC OS (ie: the window manager etc...). Even though
>this library may have a few bugs, it is still perfectly usable. I have been
>programming with RISC_OSLib for many years now and have never had any real
>problems with it, even when giving it a heavy bashing. Lots of our
What? You mean to say that you don't mind looking up *every* function call
in the manual just to remind yourself of how to spell its name? and where
to put underlines? and what letters to capitalise?
>internal software is written with RISC_OSLib and one hell of alot of third
>party software is also constructed with it.
Yes, one can tell that Edit, Draw, Paint, etc. are written with RISC_OSLib
because they *share* the same bugs!
>If it is so bad then why do so many people use it?
Well, if it took Acorn 5 years to write these libraries how long do you think
it would take an individual? Some of us can't afford to spend 2 years writing
our own libraries before we start writing code to earn money...
And believe me, it is NOT possible to simply replace bits of RISC_OSLib
because Acorn have interweaved the different "modules" so much...
(i.e. to replace dbox, you need to replace templates, resspr, etc.)
>Desktop C is a reasonably high quality product and I would not be put off
What version, pray tell, of Desktop C are YOU using? 37? 48?
Us people who don't work for Acorn are stuck with 4.00, and it is not good.
The basic coomand-line utilities are excellent, but the frontend (the
miraculous DDE) is useless, SrcEdit seems to have about 4 new features over
and above the original RISC OS 2 Edit, but about 500 new bugs, and the
RISC_OS Library shows every sign of being hacked together out of bits of
code written by various people for their own applications (edit, draw, paint,
etc.) and then shoved into a library because they "might be useful to other
people".
The biggest problem with RiscOs Lib is simply that the code is completely
non-generic. i.e. if you want to bring up a dialogue consisting of more than
one window, dbox crashes, so you have to do all the work yourself.
If you want to put dashed lines in your menus, they don't appear in the
correct places...
If you want to make the button type of your OK buttons "Release" instead of
"Click", then dbox fails to think of them as "action" buttons any more and
your program fails to do anything when you click "OK".
I still haven't worked out how to find out whether a menu "hit" was from a
click on an item or moving over it's arrow... and beleive me it is a useful
thing to know...
It is obvious that very little thought went into some portions of RISC_OSLib
and it is remarkably unprofessional and awful to use. Compare it to libraries
supplied with other compilers on the PC or mac, for example...
Not that RISC OS Lib is completely awful... about 50% is actually very good...
but would you buy a car with 4 good wheels but no engine? Not really a car...
>buying because of a few bugs that people keep griping about. Remember, the
A FEW!?!?!? Every single time I use a new Acorn routine, I stumble over a
bug, a design flaw, or something similar...
>person who started this subject appears to spend most of his time slagging
>off Acorn anyway.
Well if Acorn did things right, then nobody would have anything to gripe about
And would you prefer that Acorn thought everything was all roses and light
and therefore didn't DO anything about FIXING the RISCOSLib problem? No...
They should KNOW what people think of the library, and actually FIX some of
the problems... and if I can get them to notice me by constantly wingeing on
the net, then I'm sorry, netters, but I'm going to have to keep on...
On a different note... I got to use an A5000 for a whole day, and I was very
pleased with it... it's a very nice machine, and Acorn deserve some praise
for it... (And I only destroyed (bad params) the Hard drive ONCE!)
>James Bye
>Acorn Computers Ltd
/G=Rhodri/S=James/O=SJ-Res...@mhs-relay.ac.uk
>In <12...@acorn.co.uk> jb...@acorn.co.uk (James) writes:
>>The Library that people seem to be complaining about is RISC_OSLib, which is
>>our own interface to RISC OS (ie: the window manager etc...). Even though
>>this library may have a few bugs, it is still perfectly usable. I have been
>>programming with RISC_OSLib for many years now and have never had any real
>>problems with it, even when giving it a heavy bashing. Lots of our
>>internal software is written with RISC_OSLib and one hell of alot of third
>>party software is also constructed with it.
>Ahh....But is your software written with the release RISC_OSLib or
>versions you get correct before releasing the software?
It would be extremely stupid of James et al to do this, since it would mean
that the library calls from the software wouldn't match up with the CLib in
anyone else's machine, and any such software would be unreleasable.
---
Rhodri James * Disclaimer: These are my opinions, not
SJ Research Ltd, Cambridge * those of my company UNLESS I SAY SO!
Rhodri.James%gb.INTERSPAN.sj *
@mhs-relay.ac.uk *
or * Wombats are go!
rm...@phx.cam.ac.uk *
/G=Rhodri/S=James/O=SJ-Res...@mhs-relay.ac.uk
>The !Make utility supplied with the package seems to be some sort of
>joke. I can write a makefile in about a fifth the time it takes to
>shove everything through !Make. And, if I write my own makefile I am
>not constrained by all the silly restrictions about the number of
>commands that can be run in any one make step, etc. And, I can move
>my programs around the disc without the maker throwing a wobbly.
It's even worse if you try to use !Make from a network, because of its
endearing habit of saving data back into the application. I thought this
technique had been stamped on a long time ago, because it makes it
impossible to put the application on read-only disc, creates utter havok
when more than one person tries to use it (especially if both add projects
-- !Make only saves back project details when it shuts down!), and generally
wastes hours trying to work out what you just did to your project. Sigh.---
James
>
>>The Library that people seem to be complaining about is RISC_OSLib, which is
>>our own interface to RISC OS (ie: the window manager etc...). Even though
>>this library may have a few bugs, it is still perfectly usable. I have been
>>programming with RISC_OSLib for many years now and have never had any real
>>problems with it, even when giving it a heavy bashing. Lots of our
>
>What? You mean to say that you don't mind looking up *every* function call
>in the manual just to remind yourself of how to spell its name? and where
>to put underlines? and what letters to capitalise?
I must admit I had to refer to the manuals quite a lot when I first started
using C and RISC_OSLib. It is the same when using any language or library,
when you first use it you need to use the manual/header files to find out
how to call/use the appropriate funtions.
I find that now that I can quite easily program using RISC_OSLib without the
need to use the manuals to look up every function call I need to use. Maybe
my memory banks are better than yours :-)
I admit that the naming conventions could be better.
>
>>internal software is written with RISC_OSLib and one hell of alot of third
>>party software is also constructed with it.
>
>Yes, one can tell that Edit, Draw, Paint, etc. are written with RISC_OSLib
>because they *share* the same bugs!
What bugs are these? EMail me and let me know.
> >>If it is so bad then why do so many people use it?
>
>Well, if it took Acorn 5 years to write these libraries how long do you think
>it would take an individual? Some of us can't afford to spend 2 years writing
>our own libraries before we start writing code to earn money...
>And believe me, it is NOT possible to simply replace bits of RISC_OSLib
>because Acorn have interweaved the different "modules" so much...
>(i.e. to replace dbox, you need to replace templates, resspr, etc.)
What the hell has that got to do with the price of fish?
My question and your answer don't really tie up do they!
>>person who started this subject appears to spend most of his time slagging
>>off Acorn anyway.
>
>Well if Acorn did things right, then nobody would have anything to gripe about
>And would you prefer that Acorn thought everything was all roses and light
>and therefore didn't DO anything about FIXING the RISCOSLib problem? No...
>They should KNOW what people think of the library, and actually FIX some of
>the problems... and if I can get them to notice me by constantly wingeing on
>the net, then I'm sorry, netters, but I'm going to have to keep on...
Have you ever heard of constructive critisism or bug reports. Acorns fault
report form has been posted to the net many times and it may need to be
posted again.
It is very hard to spot fault reports or problems in the piles of
'slag-off'.
--James
James Bye
Acorn Computers Ltd
"...... and may the skin of your arse never cover a banjo!"
Dag H}kon Myrdal
>
>I admit that the naming conventions could be better.
>
But other than the naming conventions, I don't see *that* many bugs...
Why don't Acorn (or somebaody else, for that sake) supply a header-file
with macros that define more sensible names for the libraries?
That would be backwards compatible, and a quite easy task to do...
If Acorns themselves did the job, the next release of the manuals
could be up to dater; that is the main reason I haven't done it myself;
many different standards are even worse than one non-perfect...
--Dag
-member of the league for soldering freedom!-
- Omega Verksted, ED-avd, N-7034 NTH -
-----------------------------------------------------------------------------
This .sign automatically generated:
"I don't think they could put him in a mental hospital. On the other
hand, if he were already in, I don't think they'd let him out."
-----------------------------------------------------------------------------
Hi! I am a .signature virus. Copy me into your .signature to join in!
David Alan Gilbert
>gilb...@p4.cs.man.ac.uk (David Alan Gilbert) said:
.
.
>>Ahh....But is your software written with the release RISC_OSLib or
>>versions you get correct before releasing the software?
>It would be extremely stupid of James et al to do this, since it would mean
>that the library calls from the software wouldn't match up with the CLib in
>anyone else's machine, and any such software would be unreleasable.
Why ? None of the RiscOSLib is in the SharedCLib so it wouldnt matter
if you used a different version - and anyway they are backwardly compatible -
dont forget there are a lot of released programs under V3.00,V3.1B and V4.00 C
and they all run quite happily with each other.
>---
>Rhodri James * Disclaimer: These are my opinions, not
>SJ Research Ltd, Cambridge * those of my company UNLESS I SAY SO!
>Rhodri.James%gb.INTERSPAN.sj *
> @mhs-relay.ac.uk *
> or * Wombats are go!
>rm...@phx.cam.ac.uk *
Dave - gilb...@uk.ac.man.cs.p4
Jonathan Coxhead
Rhodri James writes
... creates utter havok ...
^
So who's been reading X-Men for so long that his brain's fried??
/|
(_|/
/|
(_/
/G=Rhodri/S=James/O=SJ-Res...@mhs-relay.ac.uk
Rhodri James writes
... creates utter havok ...
^
So who's been reading X-Men for so long that his brain's fried??
Careful Jonathan, or I'll tell them *all* about Jack Craft... :-)