Discussion:
DeskLib and GCCSDK
(too old to reply)
Steve Fryatt
2020-05-11 15:04:10 UTC
Permalink
I've been attempting to build a version of the current DeskLib for use in
the GCCSDK, based on the sources at https://www.riscos.info/websvn/

A minor syntactical tweak to Makefile.unix notwithstanding, it seems to do
the right kinds of things, and

make -f Makefile.unix SCL=true install

puts the expected files into ~/gccsdk/env/...

If I then try to use it to compile an application (in this case WinEd from
the same source as above), then again it seems to do the correct sorts of
thing (except that WinEd's Makefile requires a lot of modification to make
it happy with the GCCSDK), but the process soon hits several problems.

The first, which I would like to sort out before moving on to the rest, is
that the DeskLib headers installed by the process above contain several

#include "DeskLib:Core.h"

lines and similar, which GCCSDK can't sensibly resolve. I can make things
build to a point where I'm looking at a handful of genuine-looking missing
or conflicting source files in WinEd by doing a search and replace to remove
the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
this seems sub-optimal. Not least because the DeskLib docs refer to the
library being prepped for use in the GCCSDK, which suggests that this should
"just work". :-)

Is there some way to make GCCSDK happy with the files as they stand,
"DeskLib:Core.h" and the like included?

Also, where's the best place to ask about DeskLib nowadays. The last SVN
commit was 2012, and the Google Group that the documentation recommends for
support doesn't exist. Is anyone maintaining it?
--
Steve Fryatt

***@stevefryatt.org.uk
http://www.stevefryatt.org.uk/
Theo
2020-05-12 20:52:56 UTC
Permalink
Post by Steve Fryatt
The first, which I would like to sort out before moving on to the rest, is
that the DeskLib headers installed by the process above contain several
#include "DeskLib:Core.h"
lines and similar, which GCCSDK can't sensibly resolve. I can make things
build to a point where I'm looking at a handful of genuine-looking missing
or conflicting source files in WinEd by doing a search and replace to remove
the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
this seems sub-optimal. Not least because the DeskLib docs refer to the
library being prepped for use in the GCCSDK, which suggests that this should
"just work". :-)
Is there some way to make GCCSDK happy with the files as they stand,
"DeskLib:Core.h" and the like included?
Also, where's the best place to ask about DeskLib nowadays. The last SVN
commit was 2012, and the Google Group that the documentation recommends for
support doesn't exist. Is anyone maintaining it?
I don't think anyone is maintaining it. I think the GCCSDK mailing list is
probably the place to ask, as there are at least some people with commit
access to the repo.

On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.

I think the canonical would be #include "DeskLib/Core.h" which should work
in GCC as a cross compiler and natively if you are supplying the right
-I flag. I think a recent version of the DDE should also handle that.

When cross-compiling, looking at the source:
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Friscosify.c
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Funixify.c
I think #include "DeskLib:/Core.h"
would look for the file in /DeskLib:/Core.h
so if /DeskLib: were to be a symlink to the right place it might work.
I'm not familiar with the GCC internals as to whether it does anything
beyond this, maybe it does.

I think asking on the list would be an idea since someone might know, but
otherwise you could submit a patch?

Theo
Steve Fryatt
2020-05-12 21:15:50 UTC
Permalink
On 12 May, Theo wrote in message
Post by Theo
On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.
I thought similar, but almost a day on Google (on and off) found me nothing.
Post by Theo
I think the canonical would be #include "DeskLib/Core.h" which should work
in GCC as a cross compiler and natively if you are supplying the right -I
flag. I think a recent version of the DDE should also handle that.
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Friscosify.c
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Funixify.c
Post by Theo
I think #include "DeskLib:/Core.h" would look for the file in
/DeskLib:/Core.h so if /DeskLib: were to be a symlink to the right place
it might work. I'm not familiar with the GCC internals as to whether it
does anything beyond this, maybe it does.
Aha. Thanks; I'll have a play at some point.

The other option which had occurred to me, given that the library builds
fine but then causes apps which try to include it to choke, was that the
install process for GCCSDK could do some suitable search and replace of the
various header files.

The problem is that as a non-desklib user, I've no real idea what "correct
behaviour" is...
Post by Theo
I think asking on the list would be an idea since someone might know, but
otherwise you could submit a patch?
That was somewhere on the plan, if I could decide what the correct thing was
to do.

I may as well admit that the aim of this was to get to a position where I
could try and identify some of the more interesting crashiness of WinEd on
modern hardware, and submit some fixes.

:-)
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Theo
2020-05-12 22:34:30 UTC
Permalink
Post by Steve Fryatt
On 12 May, Theo wrote in message
Post by Theo
On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.
I thought similar, but almost a day on Google (on and off) found me nothing.
I have a vague recollection David Higton might have been involved, perhaps
he can remember?
Post by Steve Fryatt
Post by Theo
I think #include "DeskLib:/Core.h" would look for the file in
/DeskLib:/Core.h so if /DeskLib: were to be a symlink to the right place
it might work. I'm not familiar with the GCC internals as to whether it
does anything beyond this, maybe it does.
Aha. Thanks; I'll have a play at some point.
(oops, typo - that should be #include "DeskLib:Core.h" in the above
paragraph, in case it was unclear)
Post by Steve Fryatt
The other option which had occurred to me, given that the library builds
fine but then causes apps which try to include it to choke, was that the
install process for GCCSDK could do some suitable search and replace of the
various header files.
The problem is that as a non-desklib user, I've no real idea what "correct
behaviour" is...
It would be possible, but compilers should be able to handle the canonical
form without source modification. It's especially important if you don't
know if you're cross compiling or not, and makes a mess of eg checking out a
new copy from a source repo or comparing hashes to see if anything changed.

Picking a random piece of RISC OS source:
https://gitlab.riscosopen.org/RiscOS/Sources/Toolbox/Window/-/blob/master/c/events
that does have
#include "objects/toolbox.h"
which indicates that Norcroft is happy with that syntax.

I think therefore the right thing to do would be to patch the headers to be
in the
#include "DeskLib/Wimp.h"
format, and then Makefiles need -IDeskLib:
and the path structure should be !DeskLib.DeskLib.h.Wimp
and in !Boot you have:
*Set DeskLib$Path <Obey$Dir>.

I don't know if this would break existing Makefiles though, or are they
already broken?
Post by Steve Fryatt
Post by Theo
I think asking on the list would be an idea since someone might know, but
otherwise you could submit a patch?
That was somewhere on the plan, if I could decide what the correct thing was
to do.
It might be worth having this discussion on the list, in case anyone
disagrees?
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a position where I
could try and identify some of the more interesting crashiness of WinEd on
modern hardware, and submit some fixes.
If you would like commit access to the WinEd repo, do drop me a line...

Theo
David Higton
2020-05-13 15:00:29 UTC
Permalink
Post by Theo
Post by Steve Fryatt
On 12 May, Theo wrote in message
Post by Theo
On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.
I thought similar, but almost a day on Google (on and off) found me nothing.
I have a vague recollection David Higton might have been involved, perhaps
he can remember?
The only person I can recall as having done any development on DeskLib
in years is Rick Murray.

I did try to use it some years ago, but I couldn't get it to build and
work for me. I apologise, it's so long ago that I cannot remember any
of the details.

It must be well over a decade, maybe even two, since I actually used
DeskLib successfully. But, if you can get it to build with the tools
that you want to use, I remember that it does make an app's
infrastructure very easy to create.

David
News
2020-05-12 22:39:47 UTC
Permalink
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a position
where I could try and identify some of the more interesting
crashiness of WinEd on modern hardware, and submit some fixes.
I use WinEd with all the David Pilling software I play with, because
it is all template based. I haven't noticed any problems. I was
editing some of the DPScan templates over the last week or so without
problem.

Can you give an idea of what the problems are - I would find that
useful.
--
Chris Johnson
Steve Fryatt
2020-05-13 09:25:27 UTC
Permalink
On 12 May, News wrote in message
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a position where
I could try and identify some of the more interesting crashiness of
WinEd on modern hardware, and submit some fixes.
I use WinEd with all the David Pilling software I play with, because it is
all template based. I haven't noticed any problems. I was editing some of
the DPScan templates over the last week or so without problem.
Can you give an idea of what the problems are - I would find that useful.
The GUI is *very* unstable, to the point of being useless, on a Titanium.
For example, load WinEd, and open a new template browser. Click on the
Create Window button in the toolbar, then immediately click on Cancel.

"WinEd may have gone wrong...", which is an abort on data transfer in the
Menu_Show function (which I think is DeskLib).

There are many other examples, which tend to catch me just before I save a
file. These days, I only use it under RISC OS 5 on RPCEmu, where it is
indeed very stable. Given the age of the software, my guess is ARMv7 issues.

This is version 3.20 (September 2008). The latest that I'm aware of is 3.21
(alpha), if you build from source.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Martin
2020-05-13 10:33:27 UTC
Permalink
Post by Steve Fryatt
On 12 May, News wrote in message
Post by News
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a
position where I could try and identify some of the more
interesting crashiness of WinEd on modern hardware, and submit
some fixes.
I use WinEd with all the David Pilling software I play with,
because it is all template based. I haven't noticed any problems.
I was editing some of the DPScan templates over the last week or
so without problem.
Can you give an idea of what the problems are - I would find that useful.
The GUI is *very* unstable, to the point of being useless, on a
Titanium. For example, load WinEd, and open a new template browser.
Click on the Create Window button in the toolbar, then immediately
click on Cancel.
"WinEd may have gone wrong...", which is an abort on data transfer
in the Menu_Show function (which I think is DeskLib).
There are many other examples, which tend to catch me just before I
save a file. These days, I only use it under RISC OS 5 on RPCEmu,
where it is indeed very stable. Given the age of the software, my
guess is ARMv7 issues.
This is version 3.20 (September 2008). The latest that I'm aware of
is 3.21 (alpha), if you build from source.
I would love to see WinEd made a little more stable, as it is my
favourite template editor. Currently using a Titanium, previously
RPi3 and Iyonix.

Mind you, it only occasionally crashes for me ... and in the Load ->
New -> Create Win -> Cancel scenario it 'only' creates 128 ZeroPain
logs here. menu_Show does seem implicated, when r14 is -1 , and an
LDM from r3 at &14 in steps up to &BEC fails.

But I maybe have the advantage of having v3.22a (Oct 2008) here!
I was feeding back issues and suggestions to Adam before he lost
interest, so it may be worth trying to contact hime if you have not
already tried.

Martin
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
Steve Fryatt
2020-06-16 14:28:13 UTC
Permalink
Well, I finally got back to looking at this...

I can now mostly build WinEd from source, although I've had to comment
some code out for now to make it compile.

One oddity is that it seems to include an Error.c source file which GCC
thinks duplicates the Error.c in DeskLib. This appears to be to allow
WinEd to set its own error box titles, but there seems to be no way to
get the linker to pick WinEd's Error.o over the one in DeskLib (although
the DeskLib notes suggest that this is what should be done).
Post by Martin
Post by Steve Fryatt
This is version 3.20 (September 2008). The latest that I'm aware of
is 3.21 (alpha), if you build from source.
I would love to see WinEd made a little more stable, as it is my
favourite template editor. Currently using a Titanium, previously
RPi3 and Iyonix.
[snip]
Post by Martin
But I maybe have the advantage of having v3.22a (Oct 2008) here!
I don't suppose that you have the source to it and the associated
DeskLib? Even the 3.20 tag from SVN references what I take to be a
DeskLib function call (Pointer_SetPosition) which isn't in the DeskLib
sources in SVN; it's not used in the 3.10 tag of WinEd, so it looks like
a newish feature.

It doesn't look like a big deal to recreate, but having the original
code would be better.

Also, the version of WinEd in SVN reports itself to be 3.21a, so
presumably there are some other code mods that never made it into SVN.
Post by Martin
I was feeding back issues and suggestions to Adam before he lost
interest, so it may be worth trying to contact hime if you have not
already tried.
I managed to find an address today which didn't bounce back immediately,
so fingers crossed.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Theo
2020-06-16 15:09:32 UTC
Permalink
Post by Steve Fryatt
Well, I finally got back to looking at this...
I can now mostly build WinEd from source, although I've had to comment
some code out for now to make it compile.
One oddity is that it seems to include an Error.c source file which GCC
thinks duplicates the Error.c in DeskLib. This appears to be to allow
WinEd to set its own error box titles, but there seems to be no way to
get the linker to pick WinEd's Error.o over the one in DeskLib (although
the DeskLib notes suggest that this is what should be done).
I'm a bit puzzled by that - normally linking is done on a per-function
basis, rather than a per-file basis. In other words you might have foo.o
twice but if the functions don't overlap it's not a problem.

I assume you're doing -lDeskLib rather than trying to link all the *.o from
Desklib? Where does it talk about this in the Desklib notes?

The other thing I'd try is changing the order on the link line so that it
detects the right one first.

Quick test (on a Mac):

$ cat > test1.c
int foo(int x) { return x*2; }
$ mkdir subdir
$ cat > subdir/test1.c
int bar(int x) { return x*4; }
$ cat > main.c
int main(void) { return foo(bar(99)); }
$ gcc -o test1 main.c test1.c subdir/test1.c
[warnings about no prototypes for foo and bar]
2 warnings generated.
[succeeded]

If I make a static library:

$ gcc -c -o subdir/test1.o subdir/test1.c
$ ar -r libtest1.a subdir/test1.o
ar: creating archive libtest1.a
$ gcc -o test1 main.c test1.c libtest1.a
[succeeded]

$ gcc -o test1 -L. main.c test1.c -ltest1
[succeeded]

It is possible to have 'weak symbols' by which the linker will pick a
fallback function if one isn't explicitly declared - perhaps this is what
it's talking about?
https://en.wikipedia.org/wiki/Weak_symbol
(Unixlib has used them for years, but I'm not sure if Norcroft supports
them)
Post by Steve Fryatt
I don't suppose that you have the source to it and the associated
DeskLib? Even the 3.20 tag from SVN references what I take to be a
DeskLib function call (Pointer_SetPosition) which isn't in the DeskLib
sources in SVN; it's not used in the 3.10 tag of WinEd, so it looks like
a newish feature.
It doesn't look like a big deal to recreate, but having the original
code would be better.
Also, the version of WinEd in SVN reports itself to be 3.21a, so
presumably there are some other code mods that never made it into SVN.
If anyone wants commit access to SVN to tidy things up, I'm happy to arrange
that...

Theo
Steve Fryatt
2020-06-16 18:03:16 UTC
Permalink
On 16 Jun, Theo wrote in message
Post by Theo
Post by Steve Fryatt
One oddity is that it seems to include an Error.c source file which GCC
thinks duplicates the Error.c in DeskLib. This appears to be to allow
WinEd to set its own error box titles, but there seems to be no way to
get the linker to pick WinEd's Error.o over the one in DeskLib (although
the DeskLib notes suggest that this is what should be done).
I'm a bit puzzled by that - normally linking is done on a per-function
basis, rather than a per-file basis. In other words you might have foo.o
twice but if the functions don't overlap it's not a problem.
I assume you're doing -lDeskLib rather than trying to link all the *.o
from Desklib? Where does it talk about this in the Desklib notes?
Yes, that's what I thought... The Error.h in DeskLib says

: This header provides centralised error reporting routines, and a few
: macros to help with error reporting.

: This idea is that if you want to replace these with your own error
: reporting routines you can just link against your set instead and keep the
: function prototypes the same. An example of this is linking against
: Desklib:o.Other.SmError which provides command-line output of errors by
: writing them to stderr.

Then WinEd has its own Error.c file, which contains duplicates of some of
the routines defined in DeskLib's Error.c and Error.h, which appear to do
most of the same things in different ways.
Post by Theo
The other thing I'd try is changing the order on the link line so that it
detects the right one first.
The Makefile does

linkflags = -mlibscl -o ../!RunImage,ff8
libraries = -L$(GCCSDK_INSTALL_ENV)/lib -lDesk-scl -lFlexLib32

# Default rule
../!RunImage,ff8 : $(objects)
$(CC) $(linkflags) $(objects) $(libraries)

The order of $(objects) $(libraries) in the parameter list just affects
which of the two definitions GCC reports as being the original. $(objects)
contains the Error.o from WinEd, amongst the other WinEd object files.
Post by Theo
Post by Steve Fryatt
Also, the version of WinEd in SVN reports itself to be 3.21a, so
presumably there are some other code mods that never made it into SVN.
If anyone wants commit access to SVN to tidy things up, I'm happy to
arrange that...
It might be useful... :-)

I've already got access to the Tokenize repo, although it's been a while
since I used it.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Theo
2020-06-16 21:24:04 UTC
Permalink
Post by Steve Fryatt
On 16 Jun, Theo wrote in message
Yes, that's what I thought... The Error.h in DeskLib says
: This header provides centralised error reporting routines, and a few
: macros to help with error reporting.
: This idea is that if you want to replace these with your own error
: reporting routines you can just link against your set instead and keep the
: function prototypes the same. An example of this is linking against
: Desklib:o.Other.SmError which provides command-line output of errors by
: writing them to stderr.
Then WinEd has its own Error.c file, which contains duplicates of some of
the routines defined in DeskLib's Error.c and Error.h, which appear to do
most of the same things in different ways.
Hmm, so SmError comes from:
!DLUser.Libraries.SmallError.Error/c
in websvn:
http://www.riscos.info/websvn/listing.php?repname=DeskLib&path=%2Ftrunk%2F%21DLUser%2FLibraries%2FSmallError%2F&#a0df80822861e2ae3e282c05e0ce1f455

However that just puts it in a library and doesn't link with anything.
Post by Steve Fryatt
The Makefile does
linkflags = -mlibscl -o ../!RunImage,ff8
libraries = -L$(GCCSDK_INSTALL_ENV)/lib -lDesk-scl -lFlexLib32
# Default rule
../!RunImage,ff8 : $(objects)
$(CC) $(linkflags) $(objects) $(libraries)
The order of $(objects) $(libraries) in the parameter list just affects
which of the two definitions GCC reports as being the original. $(objects)
contains the Error.o from WinEd, amongst the other WinEd object files.
I wonder if Norcroft will pick the first function it finds and ignore the
others. For GCC you can try:
-Wl,--allow-multiple-definition

which will pass that the --allow-multiple-definition flag to the linker.
Post by Steve Fryatt
It might be useful... :-)
I've already got access to the Tokenize repo, although it's been a while
since I used it.
I've given you access to the WinEd and DeskLib repos, have fun :)

Theo
Steve Fryatt
2020-06-16 22:47:42 UTC
Permalink
On 16 Jun, Theo wrote in message
Post by Theo
I wonder if Norcroft will pick the first function it finds and ignore the
others. For GCC you can try: -Wl,--allow-multiple-definition
which will pass that the --allow-multiple-definition flag to the linker.
That's brilliant... thank you! It sorts all of the linker errors, apart from
the missing DeskLib function. :-)

With that, plus Lee's help on the GCCSDK list with the <DeskLib$Path> stuff,
I'm down to one problem with AsAsm, which I can look into further.
Post by Theo
I've given you access to the WinEd and DeskLib repos, have fun :)
Thanks!

I've branched both, stuck the missing Pointer_ function into DeskLib and
will start committing the the necessary changes to WinEd once I've sorted
out the remaining little niggles with the build.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Martin
2020-06-16 16:28:36 UTC
Permalink
Post by Steve Fryatt
Post by Martin
But I maybe have the advantage of having v3.22a (Oct 2008) here!
I don't suppose that you have the source to it and the associated
DeskLib? Even the 3.20 tag from SVN references what I take to be a
DeskLib function call (Pointer_SetPosition) which isn't in the
DeskLib sources in SVN; it's not used in the 3.10 tag of WinEd, so
it looks like a newish feature.
It doesn't look like a big deal to recreate, but having the
original code would be better.
No, sorry. Although I have lots of emails from 2008/9 about bugs and
developments, and several different beta versions, the last source I
have is v3.20

When you get to the stage of having a compilable working version I
would be happy to dig out any info about bugs & changes after that
point in development - and even to beta test it, if that would help.
There are certainly some ZeroPain bugs which could do with sorting!

Adam's snowstone riscos website page is still available, so I would
have expected the associated emails to still work - but maybe not.

I hope you manage to make progress!

Martin
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
Steve Fryatt
2020-06-16 21:19:14 UTC
Permalink
This post might be inappropriate. Click to display it.
News
2020-05-13 09:54:08 UTC
Permalink
Post by Steve Fryatt
The GUI is *very* unstable, to the point of being useless, on a Titanium.
Odd - I do all my development on a Titanium machine. I cannot
remember having problems editing existing template files, although it
is a few years since I created a completely new template file.

I'll take more notice of what is going on.
--
Chris Johnson
Alan Adams
2020-05-13 09:55:44 UTC
Permalink
Post by News
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a position
where I could try and identify some of the more interesting
crashiness of WinEd on modern hardware, and submit some fixes.
I use WinEd with all the David Pilling software I play with, because
it is all template based. I haven't noticed any problems. I was
editing some of the DPScan templates over the last week or so without
problem.
Can you give an idea of what the problems are - I would find that
useful.
I use it a lot too. The only problem I've ever encountered is on a couple
of occasions it's refused to open a template it previously created. I
don't know whether I still have an example around. If I find one, I'll let
you know.
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Jean-Michel
2020-05-13 06:50:03 UTC
Permalink
Post by Theo
Post by Steve Fryatt
The first, which I would like to sort out before moving on to the rest, is
that the DeskLib headers installed by the process above contain several
#include "DeskLib:Core.h"
lines and similar, which GCCSDK can't sensibly resolve. I can make things
build to a point where I'm looking at a handful of genuine-looking missing
or conflicting source files in WinEd by doing a search and replace to remove
the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
this seems sub-optimal. Not least because the DeskLib docs refer to the
library being prepped for use in the GCCSDK, which suggests that this should
"just work". :-)
Is there some way to make GCCSDK happy with the files as they stand,
"DeskLib:Core.h" and the like included?
Also, where's the best place to ask about DeskLib nowadays. The last SVN
commit was 2012, and the Google Group that the documentation recommends for
support doesn't exist. Is anyone maintaining it?
I don't think anyone is maintaining it. I think the GCCSDK mailing list is
probably the place to ask, as there are at least some people with commit
access to the repo.
Unless you are only looking for a GCC version only, I think Rick Murray
did it and Desklib is part of RISC OS source code, downloadable from RISC
OS OPEN.

Bonne journée.
--
Jean-Michel
Steve Fryatt
2020-05-13 09:29:11 UTC
Permalink
On 13 May, Jean-Michel wrote in message
Post by Jean-Michel
Post by Theo
I don't think anyone is maintaining it. I think the GCCSDK mailing list
is probably the place to ask, as there are at least some people with
commit access to the repo.
Unless you are only looking for a GCC version only, I think Rick Murray
did it
Rick has a hacked around version of an older version, I think. It claims to
be based on a 2004 vintage, which would mean that it misses many of the
changes of the current version in SVN, but then appears to have some
different changes of Rick's own devising.
Post by Jean-Michel
Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.
Have you got a link to that?
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Theo
2020-05-13 12:12:37 UTC
Permalink
Post by Steve Fryatt
On 13 May, Jean-Michel wrote in message
Post by Jean-Michel
Unless you are only looking for a GCC version only, I think Rick Murray
did it
Aha, that was it.
Post by Steve Fryatt
Rick has a hacked around version of an older version, I think. It claims to
be based on a 2004 vintage, which would mean that it misses many of the
changes of the current version in SVN, but then appears to have some
different changes of Rick's own devising.
Post by Jean-Michel
Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.
Have you got a link to that?
Looks like you found the thread:
https://www.riscosopen.org/forum/forums/12/topics/3405

and a previous thread on the header issue:
https://www.riscosopen.org/forum/forums/11/topics/6322
which links to another thread here:
https://groups.google.com/forum/#!topic/comp.sys.acorn.programmer/6e_j4_nGjzE

I'm happy to give commit access to anyone who wants to sort it out, as it
looks like the problem has been around for a while.

Theo
Jean-Michel
2020-05-13 15:12:25 UTC
Permalink
Post by Steve Fryatt
On 13 May, Jean-Michel wrote in message
Post by Jean-Michel
Post by Theo
I don't think anyone is maintaining it. I think the GCCSDK mailing list
is probably the place to ask, as there are at least some people with
commit access to the repo.
Unless you are only looking for a GCC version only, I think Rick Murray
did it
Rick has a hacked around version of an older version, I think. It claims to
be based on a 2004 vintage, which would mean that it misses many of the
changes of the current version in SVN, but then appears to have some
different changes of Rick's own devising.
Post by Jean-Michel
Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.
Have you got a link to that?
I have an ARMX6 and I downloaded OMAP4Dev
from:
https://www.riscosopen.org/content/downloads/risc-os-tarballs

In RiscOs.sources.lib there is a lib named Desk (not desklib)
Comparing the directoriy of headers with that of Rick desklib, it seems to
me that it is the same library. and more complete.
With Desk (from ROOL) there is no source, just the headers and the
library.

I use DDE and so I added Desk to my libraries, but I mostly use OsLib as
in your documentation: "wimp Programming in C" on your website.
Thanks for this tutorial, it should help Risc OS programmers get started.
DDE + ToolBox + Risc OS libraries and documentation are now affordable.
It's just my opinion.
--
Jean-Michel
Steve Fryatt
2020-05-13 16:25:09 UTC
Permalink
On 13 May, Jean-Michel wrote in message
In RiscOs.sources.lib there is a lib named Desk (not desklib) Comparing
the directoriy of headers with that of Rick desklib, it seems to me that
it is the same library. and more complete.
With Desk (from ROOL) there is no source, just the headers and the
library.
Desk was a "reimagining" of DeskLib sometime in the early 1990s by one of
the original developers, which involved some significant namespace and API
changes. To differentiate it from DeskLib (then at around 2.00, IIRC), it
got the version number 3.00 and the trendy name "Desk".

The idea was that everyone would upgrade, so this made sense. The
improvements made a lot of sense, too, from what I remember. Upgrading a
project to use Desk was a lot of work. Most developers didn't bother.

Now it seems that DeskLib has reached version 3.00 itself, which isn't at
all confusing.
I use DDE and so I added Desk to my libraries, but I mostly use OsLib as
in your documentation: "wimp Programming in C" on your website. Thanks for
this tutorial, it should help Risc OS programmers get started.
No problem; it's grown a bit in the past few weeks, thanks to lock-down.

:-)
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Loading...