Camelot explained
Phil Martin
development of Xara Studio (internal codename: "Camelot"), its
relationship to previous ARM-based products, and aims to clear up
several misconceptions that people have about the project.
It does not address any financial, marketing or future-of-Acorn
issues!
Development language
--------------------
Xara Studio is mainly written in C++, with subsections written in C
and 386/486 assembler.
We're using C++ as our main development language for three reasons:
1. From now on we want to write platform independent programs that
are easy to port.
2. A drawing program is inherently object-oriented and so C++ is much
better suited to expressing the algorithms involved than straight C,
or any other non-OOP language for that matter.
3. C++ has become the industry standard OOP language of choice and is
widely supported on many platforms.
We'll only port to systems that have a well-supported C++ compiler
because otherwise it's too much work (unless the rewards are worth
it). By well-supported I mean that a comprehensive set of class
libraries should exist for the platform, debugging and profiling
must be direct and easy, the compiler should run quickly in
reasonable amounts of RAM and disk space, and the code generated
must be of a high quality (identified by size and speed).
We investigated what C++ technology was available on the Acorn ARM
platforms at the beginning of the project (around July 1993) and at
that time none of the options was acceptable to us. We have not
looked at any of the recent advances in this area. If some decent
way of compiling Xara Studio for the Archy isn’t found this will be
a great shame because Xara Studio is, essentially, "ArtWorks 2" and
would make good use of the new RISC PC hardware.
At the time of writing we have well over half a million lines of C++
code in Xara Studio. It would no longer be feasible to rewrite that
code in another language - for any given platform we need a C++
compiler!
Development platform
--------------------
The development platform for Xara Studio is the PC for many reasons
(mostly beyond the scope of this doc), not least of which is that it
provides the most widely supported and most advanced C++ development
environment around, namely Visual C++.
Part of the Visual C++ package is MFC, "Microsoft Foundation Classes",
a class library that implements a lot of the common code that
everyone has to write in an application. We use MFC a lot.
We would not have considered the PC as a development platform if it
weren’t for the advent of Microsoft’s various 32-bit systems, "Only
32-bit spoken here". Win32s allows 32-bit applications to run on
Windows 3.1, Windows 95 runs 32-bit applications as standard (even
though hidden bits of the OS are still 16-bit) and Windows NT is a
32-bit OS from the ground up. Xara Studio is a 32-bit program
throughout.
GDraw
-----
GDraw is a DLL (a Dynamic Link Library, equivalent to a RISC OS
Relocatable Module) that provides raw rendering primitives to the
Xara Studio kernel. A lot of Xara Studio’s speed and major "blob
points" come from GDraw. GDraw(486) is relatively faster than
GDraw(ARM) given all the complications of comparing the processors
they run on.
The speed of GDraw comes from several areas:
1. GDraw(486) is written in hand optimised assembler.
2. The designers of the Intel 486 CPU gained a lot of speed over the
386 by identifying the most commonly used instructions and
implementing them with a "RISC-like" core. We are very careful to
make good use of those instructions in GDraw(486) and GDraw is, of
course, 32-bit throughout.
3. GDraw(486) uses different algorithms than GDraw(ARM), it is the
second generation of GDraw and as such when-and-if it is implemented
on the ARM it will be significantly faster than GDraw(ARM) as used
in ArtWorks.
4. GDraw(486) can be configured to make good use of an FPU if it’s
present. For many of GDraw’s operations it's faster to use the FPU
than to use integer maths - for that reason the 486DX version will
probably always be faster than an ARM version until an ARM comes
with an on-chip FPU.
Although GDraw(486) was originally written directly in assembler we
don't intend to use this method of development forever. It obviously
presents big problems when we come to port Xara Studio to other
processors. With that in mind we have started to implement GDraw in
C and C++. This version of GDraw will be used to perform the initial
ports to other platforms where the code it produces will be profiled
and hand optimised to get the best performance.
A great deal of Xara Studio’s overall speed is derived from the
design of the kernel. For instance, the document rendering algorithm
is very much improved over the equivalent routine in ArtWorks. The
last time we profiled document rendering, 3% of the time was spent
in the (C++) rendering algorithm - the other 97% was spent executing
GDraw primitives. As you can see, we think we have made the correct
division between what code to implement in C++ what to implement in
assembler.
Transparency
------------
Many people have asked, "Why can’t you reverse engineer transparency
into GDraw on the Archy?".
GDraw implements the primitives that render transparent objects. As
I said above, the port of GDraw to any processor other than the 486
will probably be done using C/C++ source code.
However, the transparency rendering primitives are only half the
story. To give the user access to transparency requires code to run
the user interface, code to place transparency in the document data
structures, code to deal with the import and export of transparency,
etc, etc... Most importantly, the transparency primitives require a
24-bit deep off-screen bitmap and all the support code to run it
(e.g. only create it when transparency is used in a doc, use as
little memory as poss., blit it to screen quickly, etc.).
In other words, transparency has tentacles throughout the program
and to retro-fit ArtWorks with the ability would require a lot of
work. It could be done but you must bear in mind the following
things: We have worked hard to put transparency in Xara Studio.
Studio should be portable to the Archy. The marketing people have to
decide whether it’s worth doing this sort of work on ArtWorks or not.
Phil Martin, Xara Studio Technical Manager
ph...@cconcepts.co.uk
Gavin Sallery
> We're using C++ as our main development language for three reasons:
> 1. From now on we want to write platform independent programs that
> are easy to port.
>
> 2. A drawing program is inherently object-oriented and so C++ is much
> better suited to expressing the algorithms involved than straight C,
> or any other non-OOP language for that matter.
>
> 3. C++ has become the industry standard OOP language of choice and is
> widely supported on many platforms.
Suddenly, this stand on C++ makes sense. Acorn definitely need to implement a
decent C++ environemnt on their machines (I wouldn't mind using some form of
OOP myself), or else they are going to be left behind. Perhaps seeing that CC
have a large amount of code just waiting to be ported into the best Acorn
graphics package *ever* would be a good incentive to release the relevant
libraries.... just a thought.
--
______ _________
/__ (_ \ Hertfordshire, England
\_|avin __)allery \______________________
... "Bother", said Pooh, as his bungie cord broke.
Daniel Pead
Phil Martin <ph...@cconcepts.co.uk> writes:
> It does not address any financial, marketing or future-of-Acorn
> issues!
>
I rather think that when (arguably) the major Acorn software house
announce that the next version of their flagship package is only going
to be available for Windows, they are raising a 'future-of-Acorn' issue
whether they like it or not.
> ... By well-supported I mean that a comprehensive set of class
> libraries should exist for the platform ...
OK - and here is the rub: by 'class libraries' do you mean MFC, or
would any reasonably well thought out set of class libraries do?
Lets give an example. Now, this is all graphics related and of course,
you've got your own graphics primitives, but since I'm currently trying
to port an Arc program to MFC and am currently on the graphics
routines, its at the top of my mind. I believe the principle extends
to other things.
MFC graphics is based around the Windows GDI functions. To draw a
line, you have to create a pen object, select it (saving a pointer to
the previous pen) use the lineto, moveto or polyline functions, and
then make sure you deselect the pen before you exit the redraw
function. To draw a rectangle you have a choice of several functions -
some use the current pen and fill the rectangle with the current brush
(a seperate entity to the pen which has to be created and disposed of
in a similar way) - others can be passed a brush pointer without the
hassle of selecting and deselecting. There are all sorts of
windows-specific wrinkles (e.g. you can't have a dotted line more than
1 pixel wide :-( ) which, as far as I can see, MFC can do very little
to insulate you from.
On the Arc, on the other hand, we have two choices for line/shape
drawing: 'VDU' graphics - which are fast and primitive c.f. GDI - or
the DRAWMOD functions, based around the Postscript
build-a-path-and-stroke-it model which are a damn sight more powerful
than GDI. Both have a totally different set of swings, roundabouts and
wrinkles to the Windows environment. Now, if I were writing a class
library for the Arc, one of the things I'd do is provide a good
interface to DRAWMOD. But if you are trying to port a MFC-based
program with lots of calls to pDC->SelectObject in, that isn't going to
be much use to you, is it?
MFC code is 'portable', yes - portable to Windows 95, Windows NT/Intel,
Windows NT/MIPS, Windows NT/Alpha.... notice the pattern here? AFAIK
the Mac version (which as far as I can tell is a PC-hosted cross
compiler) basically includes large chunks of Windows code (have a look
at the Mac press to see what sort of reception Word 6 - MS's first
unified Mac/PC product - is getting. People don't like it 'cos its big
and looks too much like Windows. Of course, if MS were to produce
Windows NT for PowerPC...).
An Acorn-hosted version of MFC would have to be done along similar
lines - large chunks of Microsoft-licensed code and either a port of
MSVC++ or a NT-based cross development system, large memory
requirements. I also believe that certain types of application created
with MFC/Mac are subject to Microsoft license fees (i.e. anything that
competes with a Microsoft product). Porting NT to the ARM would
probably make more sense, and might even be easier!
Basically, what I'm saying here is that unless Camelot/Xara has been
written with an extra layer of abstraction from MFC, it is only going
to be portable to other versions of Windows.
So, the question is, has Camelot really been written to be portable or
is it just written in MFC?
> The speed of GDraw comes from several areas:
> 1. GDraw(486) is written in hand optimised assembler.
<snip>
> I said above, the port of GDraw to any processor other than the 486
> will probably be done using C/C++ source code.
I meerly lay these two statements alongside for comparison...
Kevin F. Quinn
ga...@sallery.demon.co.uk (Gavin Sallery) wrote:
> In article <D4o76...@demon.co.uk> ph...@cconcepts.co.uk (Phil Martin) wrote:
>
> > We're using C++ as our main development language for three reasons:
> > 1. From now on we want to write platform independent programs that
> > are easy to port.
> >
> > 2. A drawing program is inherently object-oriented and so C++ is much
> > better suited to expressing the algorithms involved than straight C,
> > or any other non-OOP language for that matter.
> >
> > 3. C++ has become the industry standard OOP language of choice and is
> > widely supported on many platforms.
>
> Suddenly, this stand on C++ makes sense. Acorn definitely need to implement a
> decent C++ environemnt on their machines (I wouldn't mind using some form of
> OOP myself), or else they are going to be left behind. Perhaps seeing that CC
> have a large amount of code just waiting to be ported into the best Acorn
> graphics package *ever* would be a good incentive to release the relevant
> libraries.... just a thought.
pragma (INSERT_2p);
I read it that the most important bit, GDraw 2 is in Intel assembler,
mainly for speed. Doesn't exactly port in minutes, no matter how good
the target C++ environment is :} Depends if course on how much effort
has been put into the actual design.
Next, CC will be demanding that the Risc PC window environment should
look (from a programmers point of view) like NT...
--
Kevin F. Quinn * "That's not what you said when you sent him your
ke...@banana.demon.co.uk * Navel." "Novel, Baldrick, not navel."
ke...@cix.compulink.co.uk * "Well it sounds like a case of soggy grapefruits
Compu$erve: 100025,1525 * to me..." BlackAdder III
... I am Popeye of Borg. Prepare to be askimilgrated.
Richard Birkby
In article <3ivl1q$5...@unicorn.nott.ac.uk>, rs...@unicorn.nott.ac.uk (Daniel Pead) writes:
|> In article <D4o76...@demon.co.uk>
|> Phil Martin <ph...@cconcepts.co.uk> writes:
|>
|> Lets give an example. Now, this is all graphics related and of course,
|> you've got your own graphics primitives, but since I'm currently trying
|> to port an Arc program to MFC and am currently on the graphics
|> routines, its at the top of my mind. I believe the principle extends
|> to other things.
|>
|> drawing: 'VDU' graphics - which are fast and primitive c.f. GDI - or
|> the DRAWMOD functions, based around the Postscript
|> build-a-path-and-stroke-it model which are a damn sight more powerful
|> than GDI. Both have a totally different set of swings, roundabouts and
|> wrinkles to the Windows environment. Now, if I were writing a class
|> library for the Arc, one of the things I'd do is provide a good
|> interface to DRAWMOD. But if you are trying to port a MFC-based
|> program with lots of calls to pDC->SelectObject in, that isn't going to
|> be much use to you, is it?
This is really a C-assembler debate on a higher level.
In the beginning, C didn't exist (gosh!) and people programmed using a strange
programming language on punched cards. Then the EDSAC people at Cambridge
invented assembler. People saw this was the way forward. Everyone had an
assembler. Then people wanted to take their code from one machine to another, and
people saw this was hard using assembler, so the FORTRAN team was set up. People
saw this was the way forward. Eventually C/C++ came about, and most people wrote
their portable applications in this language. However there did come a time, when
most computers had GUIs attached to them, and people found that the majority of
time spent in porting one of these GUI programs was in completely rewriting the
GUI code. This was seen as bad. Hence Microsoft decided it would be good to write
a GUI interface system, that could be ported across many GUIs. This would speed
up porting time, and lots of people would give lots of money to Microsoft. This
was seen as the way forward. MFC became an ANSI standard.
This is what could happen. I'm sure you'll agree that if an ANSI standard on
generic GUI library was written, a huge ammount of time spent porting would be
saved, leaving more time for the production of better programs. Whether you'll
agree a standard should be MFC, or even like MFC is irrelevant. The fact is, that
at the moment, this is the most likely contender.
Of course people would have extensions to the library, say for a 3D user
interface, but that happens in C now. What it would standardise is the creating of
Windows and icons, the drawing of lines. Culminating in more productivity.
Just think what UNIX would be like had no one invented C.
|> Basically, what I'm saying here is that unless Camelot/Xara has been
|> written with an extra layer of abstraction from MFC, it is only going
|> to be portable to other versions of Windows.
|>
|> So, the question is, has Camelot really been written to be portable or
|> is it just written in MFC?
|>
|> > The speed of GDraw comes from several areas:
|> > 1. GDraw(486) is written in hand optimised assembler.
|>
|> <snip>
|>
|> > I said above, the port of GDraw to any processor other than the 486
|> > will probably be done using C/C++ source code.
|>
|> I meerly lay these two statements alongside for comparison...
So? It basically means their first attempt at it was in assembler. However, they
have decided to port the product, and that means rewriting it in C to be more
portable. I notice you left the part off about hand optimising this.
Richard
Daniel Pead
R.Bi...@dcs.warwick.ac.uk (Richard Birkby) writes:
> ... GUI programs was in completely rewriting the
> GUI code. This was seen as bad. Hence Microsoft decided it would be good to write
> a GUI interface system, that could be ported across many GUIs.
Sorry, back up there. Search and replace "GUIs"->"Versions of MS
Windows".
AFAIK MFC currently exists for Windows NT in its various incarnations
and the Mac.
The magazine press release I saw regarding the Mac version suggested
that it was targetted at 'corporate' programmers and not at software
houses. The price CF other versions of MFC also suggests that it is
aimed at a niche market. Word 6 for Mac - prsumably produced using MFC
- has come in for a lot of criticism regarding its speed, size and lack
of 'Mac-ness'.
MFC/Mac is reported to contain large chunks of MS code which basically
maps windows functions onto the Mac OS. It is highly propriatory, and
authors of certain types of application may have to pay royalties.
> MFC became an ANSI standard.
oh please God tell me it hasnt?
To continue your 'C vs Assembler' analogy: It has never been possible
to write totally portable programs in a high-level language if they did
any significant amount of user interaction, or used graphics. Even C
programs for UNIX have masses of #ifdefs to cope with different unices.
If you are careful, however, you can draw a clear dividing line between
the parts which are unavoidably OS dependent and those which can be
made portable, and save a vast amount of time when porting. BUT this
DOESN'T come free simply by using C - it takes careful design and
discipline. Whats more, it takes longer and may be hard to justify
unless you are actually commited to supporting multiple platforms.
If CC have written Camelot using MFC without giving any thought to
portability to other class libraries, then Acorn can produce beautiful
application frameworks and development tools until they are blue in the
face - unless they are MFC clones, Camelot would still have to be
largely rewritten. I'm sure CC don't need to be told this, and I
sincerely hope it isn't so. However, making code portable to other
class libraries when the other class libraries don't exist is a pretty
neat trick. But then if CC have been telling Acorn since '93 that only
MFC will do I think I might hazzard a guess as to why we DON'T have any
class libraries yet...
It is far from clear that a MFC implementation for the Arc would be (a)
Legal without Microsoft's blessing, (b) Technically feasible - RISC-OS
has a lot less in common with Windows than the Mac does - I think its a
safe bet that the results would only be viable on a RISC-PC or (c)
Desirable - do small Acorn software houses really want to compete with
big PC firms? How many could afford a TV ad in the middle of C4 News?
Going out on a limb here - if CC wanted to support the Acorn market,
but also branch out into PCdom then why don't they produce their own
application framework? One which could be implemented either under
RISC-OS or as a 'veneer' over MFC? And, if it is not economically or
technically feasible for (probably) the biggest Acorn software house to
do this, one wonders who they expect to do it!
Semi-relevant aside:
Interestingly, when C was designed, library functions for things like
input, output and opening files were not included in the language -
these were considered part of the OS. However, the standard book on C
programming documented many standard UNIX function calls, in order to
present programs that actually DID something. These became the
de-facto standard, and a derivative of them ended up in the ANSI
standard. This means that anybody implementing C on their OS
effectively needs to emulate some aspects of the UNIX filing system.
Since most micros are partially UNIX-inspired anyway, this is usually
trivial. However, if you have ever used C on VMS you will know that it
can be a pain in the bum getting other VMS programs to accept files
produced from C, because VMS has a record-based filing system very
different from UNIX.
---------------------------------
Daniel Pead
Shell Centre for Maths Education
Nottingham University
Ollie Cornes
> In article <D4o76...@demon.co.uk>
> Phil Martin <ph...@cconcepts.co.uk> writes:
>
> > It does not address any financial, marketing or future-of-Acorn
> > issues!
>
> I rather think that when (arguably) the major Acorn software house
> announce that the next version of their flagship package is only going
> to be available for Windows, they are raising a 'future-of-Acorn' issue
> whether they like it or not.
The comment referred to the article rather than the actions of the
company!
> MFC graphics is based around the Windows GDI functions.
In the same way that Xara Studio isn't..
> Basically, what I'm saying here is that unless Camelot/Xara has been
> written with an extra layer of abstraction from MFC, it is only going
> to be portable to other versions of Windows.
>
> So, the question is, has Camelot really been written to be portable or
> is it just written in MFC?
I think we would be foolish to restrict the product's future by building
it in such a way as to make it unable to exist without MFC.
Cheers,
Ollie.
--
\ /\ Computer Concepts Ltd Xara Ltd
( ) ol...@cconcepts.co.uk ol...@xara.co.uk
.( o ). All opinions are mine
Ollie Cornes
> I read it that the most important bit, GDraw 2 is in Intel assembler,
> mainly for speed.
Most important in what way? If we didn't have it you wouldn't get a lot of
rendering done, but on the other hand, by code volume it is a more
minor part of the program. Certainly it would be incorrect to say that
porting Studio is mainly a matter of porting GDraw.
> Doesn't exactly port in minutes, no matter how good
> the target C++ environment is :} Depends if course on how much effort
> has been put into the actual design.
It would be ported using C/C++ and optimised when/where necesary by
hand - but like I say it's only one bit that needs porting.
> Next, CC will be demanding that the Risc PC window environment should
> look (from a programmers point of view) like NT...
Do you have a problem with this? Demanding that it's totally different
wouldn't make life too easy!
Regards,
Daniel Pead
ol...@cconcepts.co.uk (Ollie Cornes) writes:
> I think we would be foolish to restrict the product's future by building
> it in such a way as to make it unable to exist without MFC.
Well, thats good news. Honestly, making it totally MFC dependent
wouldn't be that foolish - Windows in all its flavours [1] is a pretty
big market - just very, very bad news for the Acorn market. OK, yes,
going head-to-head with Corel and Adobe while simultaneously burning
your bridges could be, er, inadvisable...
[1] Can't comment on the Mac version except that I'll believe it when I
see it and I can't afford the 2000 quid (plus the cost of an NT setup)
to see it until I believe it...
Daniel Pead
> It would be ported using C/C++ and optimised when/where necesary by
> hand - but like I say it's only one bit that needs porting.
(Tries hard to get out of flame mode and into honest curiosity mode)
I'd have thought that hand-translating well documented assembler from
one CPU to another was rather easier than hand-optimising compiler
output (human readability of output is not,AFAIK, a priority in
compiler design).
Surely, as soon as you've started hand-optimising, you've lost the
advantages of common source code and easy maintainance that go with
C/C++?
>
> > Next, CC will be demanding that the Risc PC window environment should
> > look (from a programmers point of view) like NT...
>
> Do you have a problem with this? Demanding that it's totally different
> wouldn't make life too easy!
I think the question is how far it is possible to make the programmers
interface for the Risc PC look like NT without consequently making the
USER interface look like NT [1]; and whether the effort thus spent
would be better applied to making the RISC-PC support multiple native
OSs.
If I knew more about 'X' then I'd suggest that, if we have to have an
'industry standard' API, that 'X' would be a better choice, since that
it has been designed from the ground up to support multiple user
interfaces and diverse hardware. Maybe an X-head would care to
comment? Fancy being able to run the PROPER version of Mosaic on a
RISC-PC?
[1] I don't hate Visual C++ and MFC - they are very impressive products
- I still think that the windows GUI absolutely sucks. Windows 95, to
quote a CC .sig, isn't ready yet and Windows NT + Win95 GUI (I forget
the codename - some US city or other) is even less ready.
Clive...@armltd.co.uk
> However, if you have ever used C on VMS you will know that it
>can be a pain in the bum getting other VMS programs to accept files
>produced from C, because VMS has a record-based filing system very
>different from UNIX.
Ah, but not as different as the MVS/XA filing system. As well as
multiple record/block-based file structures, there is the added
complication of EBCDIC.
I've done quite a lot of programming on an IBM 3084Q mainframe using
Norcroft C. Very interesting...
--Clive.
(Disclaimer: I wouldn't believe a word of this if I were you...)
Dr M.R. Clark
complete answer to building a stronghold in multiple markets.
Most of my colleagues are committed to Mac systems and in the past have nearly
all raved about Microsoft applications such as Word. However a large number of
them are so dissapointed with Word 6.0 on the Mac that they are staying with
5.1 or moving over to WordPerfect. Essentially in porting the software across
from the PC development platform Microsoft have produced what many consider
to be a very unwieldy, memory hungry, clumsy version of their product.
--
o/ \\ // |\ ,_ o Mike Clark, mr...@cus.cam.ac.uk
<\__,\\ // __o | \ / /\, C.U. Dept. Pathology "a mountain climbing
"> || _`\<,_ |__\ \> | immunology lecturer, antibody engineer and
` || (_)/ (_) | \corn computer user" (Clan No. 1007)
michael....@ncl.ac.uk
>If I knew more about 'X' then I'd suggest that, if we have to have an
>'industry standard' API, that 'X' would be a better choice, since that
>it has been designed from the ground up to support multiple user
>interfaces and diverse hardware. Maybe an X-head would care to
>comment? Fancy being able to run the PROPER version of Mosaic on a
>RISC-PC?
much slower than even WinMosaic and I'm at loss to know why, not to mention
it can't handle transparent .gif files (nor can WinMosaic, but who cares),
and has great difficulty loading more than a couple of small .gifs at a time.
As far as I can tell, it's a fault in way mosaic interprets html. But aside
from that I'm not a big fan of X.
Mike Harrison,
UNIX, PC, MAC - do these people have no taste?
Ale Terlevich
>In article <3j46ha$h...@unicorn.nott.ac.uk>, rs...@unicorn.nott.ac.uk (Daniel Pead) says:
>>If I knew more about 'X' then I'd suggest that, if we have to have an
>>'industry standard' API, that 'X' would be a better choice, since that
>>it has been designed from the ground up to support multiple user
>>interfaces and diverse hardware. Maybe an X-head would care to
>>comment? Fancy being able to run the PROPER version of Mosaic on a
>>RISC-PC?
>No, much as I hate to say this, I'd run Netscape on windows. X-mosaic seems
>much slower than even WinMosaic and I'm at loss to know why, not to mention
>it can't handle transparent .gif files (nor can WinMosaic, but who cares),
Ale.
Kevin F. Quinn
ol...@cconcepts.co.uk (Ollie Cornes) wrote:
> In article <19950228....@banana.demon.co.uk> ke...@banana.demon.co.uk (Kevin F. Quinn) said:
>
> > I read it that the most important bit, GDraw 2 is in Intel assembler,
> > mainly for speed.
>
> Most important in what way? If we didn't have it you wouldn't get a lot of
> rendering done, but on the other hand, by code volume it is a more
Of course, there's lies, damn lies and code metrics :)
> minor part of the program. Certainly it would be incorrect to say that
> porting Studio is mainly a matter of porting GDraw.
The original message did say that GDraw 2 was a key part, and the
reason why transparency isn't in Artworks. It certainly sounds like
a pretty major part - after all if it does the real work of rendering,
the rest is pretty much user interfaces and file handling.
Given that GDraw 2 is in assembler, it does bring into question the
assertion that lack of a C++ compiler with lots of object libraries is
the reason why Artworks doesn't have the transparency feature.
I would expect that the real reason, well the several real reasons
involve cost, resourcing, and probably not least politics.
> > Next, CC will be demanding that the Risc PC window environment should
> > look (from a programmers point of view) like NT...
>
> Do you have a problem with this? Demanding that it's totally different
> wouldn't make life too easy!
I didn't say anything about demanding that it be totally different.
You're putting words into my fingers.
with Throw_Away_Statements;
use Throw_Away_Statements;
Of course, if the programming environment looked like that for NT,
what price X compatibility?
--
Kevin F. Quinn * "That's not what you said when you sent him your
ke...@banana.demon.co.uk * Navel." "Novel, Baldrick, not navel."
ke...@cix.compulink.co.uk * "Well it sounds like a case of soggy grapefruits
Compu$erve: 100025,1525 * to me..." BlackAdder III
... File not found. Should I fake it? (Y/N)
Ollie Cornes
> Also, does anyone have any idea on the availability of Xara Studio. Since I
> am going to have a PC foisted on me eventually, I may as well have some
> decent software for it.
Decent software! Why thankyou! Couple of months' 'til release.
It also runs extremely happily on a PC card in the Risc PC.
> (Will Impression get a 'load Studio file' option?)
It exports ArtWorks EPS & loads of bitmap formats, so there are ways to
do it - the bitmap option is in some ways preferable 'cos you get the
anti-aliasing, but it all sorta depends..
Tony Howat
R.Bi...@dcs.warwick.ac.uk (Richard Birkby) wrote:
[snip]
> Just think what UNIX would be like had no one invented C.
Still written in B I guess...
Tony.
------------/\/-----------------------------/\/----------------------------
Tony Howat : tho...@xargle.demon.co.uk : Southport, Merseyside U.K.
------------/\/-----------------------------/\/----------------------------
Assembly was the first against the wall when the revolution came--COBOL's
next
---------------------------------------------------------------------------
Richard Birkby
as I remember. (probably at least since version 2) WinMosaic after 2.2(?) can
handle transparent gifs, but you need Win32s to use it.
BTW I prefer Netscape anyway.
BTBTW Why is Fresco a subtle pun?....Nicko...
Richard
Samuel Penn
Cornes) writes:
# In article <3j3a8v$3...@usgj.novell.co.jp> lit...@summit.novell.com (Malcolm
Lithgow) said:
#
# > Also, does anyone have any idea on the availability of Xara Studio. Since
I
# > am going to have a PC foisted on me eventually, I may as well have some
# > decent software for it.
#
# Decent software! Why thankyou! Couple of months' 'til release.
#
# It also runs extremely happily on a PC card in the Risc PC.
#
# > (Will Impression get a 'load Studio file' option?)
#
# It exports ArtWorks EPS & loads of bitmap formats, so there are ways to
# do it - the bitmap option is in some ways preferable 'cos you get the
# anti-aliasing, but it all sorta depends..
Why can't you just use the full WYSIWYG option in Impression? Surely this
will give an anti-aliased image of a non-bitmap file exported from Xara,
just as it does for 'normal' Artworks files?
--
Sam.
Malcolm Lithgow
: [Very good summary of Xara Studio development issues deleted.]
Thanks very much, Phil. Your article was very informative.
BTW, just out of interest: how much did Quill for the Atari ST contribute
to Impression 1.0? Were there lots of ideas in Quill that found their
true home in Impression?
Also, does anyone have any idea on the availability of Xara Studio. Since I
am going to have a PC foisted on me eventually, I may as well have some
decent software for it. (Will Impression get a 'load Studio file' option?)
: Xara Studio is mainly written in C++, with subsections written in C
: and 386/486 assembler.
: We're using C++ as our main development language for three reasons:
: 1. From now on we want to write platform independent programs that
: are easy to port.
: 2. A drawing program is inherently object-oriented and so C++ is much
: better suited to expressing the algorithms involved than straight C,
: or any other non-OOP language for that matter.
: 3. C++ has become the industry standard OOP language of choice and is
: widely supported on many platforms.
Did CC ever consider writing their own language and development
evironment, making it freely available, and then using the various free
ports of it to port Studio? That way, if the dev. environment became as
popular like Linux, and the implementations were pretty reasonable,
you'd save yourself a lot of work (porting to different class libraries,
etc.). This is a (possibly silly) idea I've had for quite a while. The
closest real thing to it is Oberon.
Have fun,
Malcolm. -lit...@uslp.usl.com
Kevin F. Quinn
i...@intrac.demon.co.uk (Ian Griffiths) wrote:
> Kevin F. Quinn (ke...@banana.demon.co.uk) wrote:
>
> : The original message did say that GDraw 2 was a key part, and the
> : reason why transparency isn't in Artworks. It certainly sounds like
> : a pretty major part - after all if it does the real work of rendering,
> : the rest is pretty much user interfaces and file handling.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> that small and insignificant section...
From a programming point of view, that is so. The Wimp already does
most of the work for you. And it's the sort of thing that if you've
done it once, you can do it again without too much difficulty.
> Most window-based applications are almost ALL user interface code.
The point is, if CC have designed it so that the GUI-specifics are
separated properly from the rendering algorithms and the database,
which would seem the obvious way to do it, then it should be a fairly
straightforward job to re-write the GUI bits for RiscOSLib et. al.
Now the database part is ripe for object-orientation; but there was
no mention of that. And they've already said that important bits
for rendering are in assembler (and hence are such that there is
no need for a C++ compiler).
> : Given that GDraw 2 is in assembler, it does bring into question the
> : assertion that lack of a C++ compiler with lots of object libraries is
> : the reason why Artworks doesn't have the transparency feature.
>
> Didn't you read the first post in this thread?
No I didn't - I'm just making things up as I go along :->
There was a section on transparency, which said that transparency is
part of GDraw 2, and that to get it into the Arc. version would
require porting to C/C++ first. Assuming that GDraw is all algorithms
and stuff, and as such doesn't use anything from these object
libraries everybody keeps talking about, then C would be perfectly
good for that, probably better as it's the bit that needs to go fast.
> : Of course, if the programming environment looked like that for NT,
> : what price X compatibility?
>
> Que?
That was a comment about whether software written for the NT
programming environment is going to port to X as easily as it
would(n't) to RiscOSLib. It was somewhat of a throw-away statement
though (which you conveniently omitted to quote...)
--
Kevin F. Quinn * "That's not what you said when you sent him your
ke...@banana.demon.co.uk * Navel." "Novel, Baldrick, not navel."
ke...@cix.compulink.co.uk * "Well it sounds like a case of soggy grapefruits
Compu$erve: 100025,1525 * to me..." BlackAdder III
... Computers can never replace human stupidity.
Ben Laughton
>
> I too think that there are some dangers in assumming that portable code is the
> complete answer to building a stronghold in multiple markets.
> Most of my colleagues are committed to Mac systems and in the past have nearly
> all raved about Microsoft applications such as Word. However a large number of
> them are so dissapointed with Word 6.0 on the Mac that they are staying with
> 5.1 or moving over to WordPerfect. Essentially in porting the software across
> from the PC development platform Microsoft have produced what many consider
> to be a very unwieldy, memory hungry, clumsy version of their product.
Did you know that Microsoft are now releasing something called Word 6a for the
Mac. This is intended to address the speed complaints (I have no idea to what
extent). Read the News section in the latest issue of Computer Shopper for
more info.
Ben
Richard May
DP>OK - and here is the rub: by 'class libraries' do you mean MFC, or
DP>would any reasonably well thought out set of class libraries do?
I spoke to some people on the Xara stand yesterday at the Windows show. It
would appear that they do regard MFC as the only option. Since no other
platform has an equivalent to thr MFC, the nearest alternative platfrom would
almost certainly be OS/2, therefore I hoped that they would be porting Studio
to OS/2 since my Warp based PC will not be able to run Studio under WinOS2.
OS/2 has an alternative class library from Borland (namely OWL). However they
have no plans to develop for OS/2 since there is no MFC. If OS/2 is out, it
does not look at all good for Acorn, which is even further waway from the
Windows model.
Richard May.
Ollie Cornes
> In article <1995Mar4.0...@intrac.demon.co.uk>,
> i...@intrac.demon.co.uk (Ian Griffiths) wrote:
>
> > Kevin F. Quinn (ke...@banana.demon.co.uk) wrote:
> >
> > : The original message did say that GDraw 2 was a key part, and the
> > : reason why transparency isn't in Artworks. It certainly sounds like
> > : a pretty major part - after all if it does the real work of rendering,
> > : the rest is pretty much user interfaces and file handling.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > that small and insignificant section...
>
> From a programming point of view, that is so. The Wimp already does
> most of the work for you. And it's the sort of thing that if you've
> done it once, you can do it again without too much difficulty.
Believe the guy - you are incorrect. GDraw is a very important part of
Studio, but it is only one part of a very large and complex system.
> The point is, if CC have designed it so that the GUI-specifics are
> separated properly from the rendering algorithms and the database,
> which would seem the obvious way to do it, then it should be a fairly
> straightforward job to re-write the GUI bits for RiscOSLib et. al.
It's not just the GUI bits that need to be ported.. As to using RiscOSLib..
> No I didn't - I'm just making things up as I go along :->
I do wonder..
> There was a section on transparency, which said that transparency is
> part of GDraw 2, and that to get it into the Arc. version would
> require porting to C/C++ first.
"Porting Studio to the Arc" is not equivalent to "porting GDraw to
the Arc".
> Assuming that GDraw is all algorithms and stuff, and as such
#################################
Hmm.
Ollie Cornes
> I spoke to some people on the Xara stand yesterday at the Windows show. It
> would appear that they do regard MFC as the only option. Since no other
> platform has an equivalent to thr MFC, the nearest alternative platfrom would
> almost certainly be OS/2, therefore I hoped that they would be porting Studio
The nearer the library is to MFC the easier it would, in theory, be for
us.
> to OS/2 since my Warp based PC will not be able to run Studio under WinOS2.
> OS/2 has an alternative class library from Borland (namely OWL). However they
> have no plans to develop for OS/2 since there is no MFC. If OS/2 is out, it
> does not look at all good for Acorn, which is even further waway from the
> Windows model.
If IBM can keep a little more up-to-date with the version of the Win32 API
they support (i.e. what they're failing to do at the moment..) Studio
will run on OS/2. We haven't discounted doing a native OS/2 version.
Ian Griffiths
: In article <D4o76...@demon.co.uk>
: Phil Martin <ph...@cconcepts.co.uk> writes:
: > It does not address any financial, marketing or future-of-Acorn
: > issues!
: >
: I rather think that when (arguably) the major Acorn software house
: announce that the next version of their flagship package is only going
: to be available for Windows, they are raising a 'future-of-Acorn' issue
: whether they like it or not.
I think his point was that his -->message<-- didn't raise such points.
: > ... By well-supported I mean that a comprehensive set of class
: > libraries should exist for the platform ...
: OK - and here is the rub: by 'class libraries' do you mean MFC, or
: would any reasonably well thought out set of class libraries do?
[snip, but hopefully leaving in an important point summing up the spirit
of what's been deleted] :
: But if you are trying to port a MFC-based
: program with lots of calls to pDC->SelectObject in, that isn't going to
: be much use to you, is it?
No, but I don't expect Camelot does go calling pDC->SelectObject all
that often. As has been mentioned before it does all its drawing using
its own routines and just uses the GDI to plot a bitmap to the screen.
That's not a large amount of code to alter.
I do actually agree with your point I just think you chose the least
appropriate example you could have done. Mr. Martin said that their
code relies heavily on MFC. Presumably much of this is in the functionality
specific to MFC other than the GDI, e.g. the way it does toolbars, and
indeed Windows controls in general perhaps. (I don't know - I'm not
a programmer in the Camelot team.)
But I get the impression that for ease of porting they need MFC.
On the other hand, for lots of things MFC works in the obvious way -
it is difficult imagining how you would implement much of it any
other way, fundamentally. So for any set of FCs that give the same
overall functionality of most of what MFC offers, there is probably
a relatively simple mapping between to two for a lot of things. This
means that you could conceivably create some form of veneer between
the two.
That's obviously a highly non-trivial task, but porting's rarely easy.
: Porting NT to the ARM would
: probably make more sense, and might even be easier!
Um... Possibly. I'd rather see that. :-)
: > The speed of GDraw comes from several areas:
: > 1. GDraw(486) is written in hand optimised assembler.
: <snip>
: > I said above, the port of GDraw to any processor other than the 486
: > will probably be done using C/C++ source code.
: I meerly lay these two statements alongside for comparison...
:-)
Maybe they realised just how far they overshot in terms of beating the
competition on the PC and realise they don't have to try so hard next
time.
--
Ian Griffiths | Coming to you from the hard shoulder
i...@intrac.demon.co.uk | of the Information Superhighway
Ian Griffiths
: - I still think that the windows GUI absolutely sucks. Windows 95, to
: quote a CC .sig, isn't ready yet and Windows NT + Win95 GUI (I forget
: the codename - some US city or other) is even less ready.
That would be Cairo wouldn't it? :-)
Ian Griffiths
: I think the question is how far it is possible to make the programmers
: interface for the Risc PC look like NT without consequently making the
: USER interface look like NT [1]; and whether the effort thus spent
: would be better applied to making the RISC-PC support multiple native
: OSs.
Not too hard. Not if you're just worried about the appearance. If
you're worried about semantics of operations then that's more
tricky, but there aren't that many differences.
: If I knew more about 'X' then I'd suggest that, if we have to have an
: 'industry standard' API, that 'X' would be a better choice, since that
: it has been designed from the ground up to support multiple user
: interfaces and diverse hardware. Maybe an X-head would care to
: comment?
All very well but the the X server just supplies a set of primitives.
As for APIs, well there's no reason not to run Windows applications
(and therefore MFC apps) under X, given an appropriate WABI implementation.
As for the programming interfaces supplied with X (XLib, Xt etc.), erm,
all very well but I much prefer MFC to be honest. X is all rather
complex, more than it needs to be.
: Fancy being able to run the PROPER version of Mosaic on a
: RISC-PC?
Well netscape looks just as good on NT as it does on X. (I know I've
got both versions.)
Ian Griffiths
: The original message did say that GDraw 2 was a key part, and the
: reason why transparency isn't in Artworks. It certainly sounds like
: a pretty major part - after all if it does the real work of rendering,
: the rest is pretty much user interfaces and file handling.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that small and insignificant section...
Most window-based applications are almost ALL user interface code.
: Given that GDraw 2 is in assembler, it does bring into question the
: assertion that lack of a C++ compiler with lots of object libraries is
: the reason why Artworks doesn't have the transparency feature.
Didn't you read the first post in this thread?
: Of course, if the programming environment looked like that for NT,
: what price X compatibility?
Que?
Ben Laughton
>
> In article <1995Mar4.0...@intrac.demon.co.uk>,
> i...@intrac.demon.co.uk (Ian Griffiths) wrote:
>
> > Kevin F. Quinn (ke...@banana.demon.co.uk) wrote:
> >
> > : The original message did say that GDraw 2 was a key part, and the
> > : reason why transparency isn't in Artworks. It certainly sounds like
> > : a pretty major part - after all if it does the real work of rendering,
> > : the rest is pretty much user interfaces and file handling.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > that small and insignificant section...
>
> From a programming point of view, that is so. The Wimp already does
> most of the work for you. And it's the sort of thing that if you've
> done it once, you can do it again without too much difficulty.
>
> > Most window-based applications are almost ALL user interface code.
>
> The point is, if CC have designed it so that the GUI-specifics are
> separated properly from the rendering algorithms and the database,
> which would seem the obvious way to do it, then it should be a fairly
> straightforward job to re-write the GUI bits for RiscOSLib et. al.
Don't do that to me. Its painful when I laugh that much. RISC_OSLib
was bad enough even on the tiny little programs that I have written
(when compared to the likes of what CC churn out) - the though of
doing the Artworks/Studio interface using RISC_OSLib makes me cringe.
I'm sure it would be nigh on impossible - too many bugs etc. Anyway,
RISC_OSLib is practically dead and buried - hooray! Long live
whatever comes next?
Ben
Ben Jefferys
[trash]
> It is far from clear that a MFC implementation for the Arc would be (a)
> Legal without Microsoft's blessing
Hence recently "dealings" between MS and Acorn?
--
_ ._ _ _ _
_)_\| |_ _ _ _ )|/( | Ben Jefferys
_)_ | |_| | |_ \| _) | B...@qsure.demon.co.uk
_______'_____________/ \_____________________
Daniel Pead
B...@qsure.demon.co.uk (Ben Jefferys) writes:
> > It is far from clear that a MFC implementation for the Arc would be (a)
> > Legal without Microsoft's blessing
>
> Hence recently "dealings" between MS and Acorn?
Please, no...
Anyhow - if people are smarting at 250 quid for C5, what are they going
to say about two grand plus a complete NT workstation (which is what
you need for MFC/Mac)?
Tim Browse
>
> In article <19950301....@cconcepts.co.uk>
> ol...@cconcepts.co.uk (Ollie Cornes) writes:
>
> > It would be ported using C/C++ and optimised when/where necesary by
> > hand - but like I say it's only one bit that needs porting.
>
> (Tries hard to get out of flame mode and into honest curiosity mode)
>
> I'd have thought that hand-translating well documented assembler from
> one CPU to another was rather easier than hand-optimising compiler
> output (human readability of output is not,AFAIK, a priority in
> compiler design).
Hand-optimising does not necessarily mean that we take the output of
the compiler, and optimise that. In fact, I'd be very surprised if we
did. It means (at worst) that we re-implement in assembler from
scratch. Experience shows (and the Camelot project bears this out)
that few routines are that speed critical that they cannot be done
in a HLL. This is why so little of Camelot is in assembler.
>
> Surely, as soon as you've started hand-optimising, you've lost the
> advantages of common source code and easy maintainance that go with
> C/C++?
No. For the simple reason that when you start hand-optimising, it
doesn't follow that you throw the other 500,000 lines of HLL code out
of the window and re-implement those in assembler too.
Even so, there are ways to achieve portability. For example, the
MS Word formatter is in C, but they have an assembler version which
is (supposed to be) functionally identical. Whenever changes are
made they throw the same test data at both and check that the results
are identical. That way they can still see the overall logic of
the code in a HLL for maintenance/bug-fixing purposes, but they
also have the advantage that the speed critical routine is fast
because it has been implemented directly in assembler.
> [1] I don't hate Visual C++ and MFC - they are very impressive products
> - I still think that the windows GUI absolutely sucks. Windows 95, to
> quote a CC .sig, isn't ready yet and Windows NT + Win95 GUI (I forget
> the codename - some US city or other) is even less ready.
^^^^^^^^^^^^^^^
And how do you know that? You never know what might be happening
at Redmond... :->
A couple of other points - as for an 'MFC-clone' on Acorn platforms
only being viable on a Risc PC, Camelot would probably only be
viable on a Risc PC. Transparency requires large off screen bitmaps
and without >4Mb RAM or virtual memory, this becomes a little tricky.
Camelot as a program is also big, but then it does do a lot.
Regarding C/C++ for GDraw - i.e. why did Phil say that we would do
future porting of GDraw via C/C++ when it is in assembler? Well, if
the poster who was puzzled by this had read the original message
carefully, he would have seen that when we port GDraw, we will port
it to C++, and then optimise for the target processor. The developers
of GDraw have commented that an architecture such as the PowerPC
(i.e. a PowerMac) would probably give very good performance even
with C++ code. Having GDraw in C++ means that we when porting to
another platform we can also get a version running that much quicker.
And also, there do seem to be a few people that think GDraw is
the most difficult and complex part of Camelot. Well, sorry, but
I'm afraid you're seriously mistaken, as I've said before. I'd only
have to show you the stats for manpower spent on various sections of
Camelot (which I can't cos it's secret :->) to make you realise that.
GDraw is, when it comes down to it, a reasonably simple set of
algorithms that have been implemented to maximum efficiency because
they are so speed critical. Camelot is full of systems that are
much more complex and sophisticated. This is not to say that GDraw
is not a 'clever' bit of code, or is not implemented well - on the
contrary, it's implemented very well, but it's just not the
'cleverest' code in Camelot.
And try asking someone who's written a sizeable amount of code to do
"just GUI and file handling stuff" and see how simple they think it
is. UI design and implementation is one of the most time-consuming
jobs in developing a GUI application. If you do it right, that is.
And oh yes - Camelot really is portable. There is an extremely clear
line that can be drawn throughout the entire source code that
separates portable from non-portable code. There are different
degress of 'non-portability', such as MFC code, Windows SDK code, and
assembler, but it is all most definitely completely separate from the
'kernel' code, which is (a) the vast majority of the code, and (b)
completely portable. Any Camelot developer who violates this rule
is usually shot at dawn :-).
Now unfortunately, despite the fact that most of Camelot is portable,
the size of the project is such that this non-portable section still
constitutes a large amount of code. (i.e. what I'm saying is that
e.g. 5% of 1 million lines of code is still a lot of code!)
So the ideal (in terms of expense) porting solution for, e.g.
RISC OS, would be an MFC class library. This means we can keep much
of our 'non-portable' code and it would still work ok. We'd have to
rewrite SDK code and assembler, of course, but that would be all.
Or, next down the scale is we use an existing RISC OS class library.
This means we have to ditch our MFC code, and rewrite most of the
OS-dependent code, but we don't have to write all the OS libraries
(if you see what I mean) because it's already there in the class
library. The flaw in this plan is the use of the word 'existing' in
the first sentence of this paragraph. Also, this class library
would have to be usable and realistic - a class library knocked up
without talking to any Acorn developers about the features and
architecture they want first would probably be a bit of a mess, but
hopefully Acorn will have learned from the Riscoslib debacle that
it's best to ask your developers before you start coding a new
library.
Lastly, and most expensively, we could just take Acorn's ToolBox (or
whatever), throw away all the non-kernel code in Camelot, *and*
implement our own class library to boot. It can be seen that for a
project the size of Camelot this is not a trivial undertaking, and
hence is a serious expense. Coupled with the fact that a Risc PC
would be required to run Camelot effectively, and that not many
Risc PCs have been sold (I don't know the exact figures), CC, as a
business has to weigh up the development costs against the potential
market. There are also resource implications too.
If you want an honest answer, then I personally really don't know if
we'll ever see Camelot on an Acorn platform. As I've indicated, it
depends to a certain extent on the development environment and class
libraries supplied by Acorn. I wouldn't say that we *can't* port
Camelot without an Acorn MFC clone - just that it would be more
difficult, and hence more time-consuming and expensive. It may be
so expensive for the predicted return that for all intents and
purposes CC as a business can't afford to do it. But then again,
it may not. Certainly, having a high quality class library
available for RISC OS would increase Camelot's chances of being
ported.
And the last thing to affect these decisions is politics, by the way.
It does still affect them, but it's pretty minor.
Having said that (:->), being slagged off and being referred to as
rats leaving a sinking ship (a ship some would argue we've helped
keep afloat for a good few years) does not predispose CC on a company
or personal level towards providing an Acorn version of Camelot.
But as I said, there are far bigger problems than this to solve in
considering a port of Camelot.
Just my opinion, of course...
Tim Browse
Software Engineer, Computer Concepts Ltd/Xara Ltd
t...@cconcepts.co.uk/t...@xara.co.uk
"This stuff we do...it isn't ready yet."
PS. My Pentium PC's arrived btw...Snowbarn in under a second :-))))
Jeremy Bradley
> PS. My Pentium PC's arrived btw...Snowbarn in under a second :-))))
>
I remember a chance letter from one of you lot in PCW which mentioned
that Corel Draw did Snowbarn on a Pentium in 17 seconds...
..so by and large under one second is pretty healthy!
Re: the rest of your 157 line post
People on this news group are _very_much_ aware of how CC has done a
fantastic job for the Acorn platform and market...
..so much so that (speaking personally) I would go where the software
went. ie if you stopped producing software for the Arc and instead
continued to develop on the PC... I would, very reluctantly, change
platforms. I have no wish to ever end up using MS Word and Corel DRAW.
for the majority of my work. (I only say that because I've tried to)
BUT... there is an interesting and not altogether subtle difference
between the Acorn market and the PC market... and it may have something
to do with the 1000 fold increase in customer base. The PC market is
pretty cut-throat (as I'm sure you're aware) and although I hope Xara
Studio challenges Corel (because it ought to) there hasn't been a
fantastic track record in this department.
A notable contender is ProDraw which I believe converted from the Amiga
and was widely tipped to be the ultimate Corel-killer application
but despite a pretty aggressive marketing campaign (which I'd be
surprised if CC could match) has never really made an inroad into the
market.
Also you may (possibly justifiably) feel that Acorn hasn't exactly
treated you fantastically given your position as its 'premier'
developer - this is more likely to be by accident or mismanagement
rather than by mallicious intent.
But "This stuff that we make" has on more than one occasion used
anti-competitive (strongARM:-) tactics to dump all over its
competitors / rivals / best developers (large and small)
(see the last 15 years of postings to alt.folklore.computers)
And before you say ... "yes but we're too small..." I might point
out numerous tiny companies (in comparison) who 'got into bed' with
MS over some piece of software or other and mysteriously found their
code materialise in the next version of some bigger product.
..unpaid for, uncredited and generally very little you can do about
it. The situation is very similar to the drugs industry... where giants
would much rather go to court (for years at a time) than spend the
R&D necessary to develop a product - and so they blatently copy it.
This may sound like the ramblings of a paranoid individual but I have
noticed that MS is currently demoing Win95 with Camelot - I understand
that this is to show off the "fantastic graphics redraw" on Win95 -
despite the fact that Camelot uses the proprietry GDraw system.
Well if in the next year before release Win95 mysteriously gets
15 times faster at screen redraw... you may want to check it out :-)
All the best in the PC market
(A very brave decision... cf: "Yes Minister")
--Jeremy.
Malcolm Lithgow
: People on this news group are _very_much_ aware of how CC has done a
: fantastic job for the Acorn platform and market...
Hear, hear.
: ..so much so that (speaking personally) I would go where the software
: went. ie if you stopped producing software for the Arc and instead
: continued to develop on the PC... I would, very reluctantly, change
: platforms.
Erm. I'm not sure that CC is quite that invaluable. While the majority
of my work on my Risc PC (mostly amateur DTP) is done on CC software
(Publisher, ArtWorks, and the Turbo Drivers) I don't think CC is that
key to my setup. For example, it seems that Techwriter is a good WP, and
Ovation II (?) is apparantly shaping up to be pretty good.
Personally, I think that if you took CC stuff and dumped it into
Windows, while it would be great Windows software, it would still not
compare too well even with slower/less featured Acorn software. I think
the Risc OS environment gives enormous useability. I'm reserving
judgement on useability improvements in Windows 95, but MS's track
record is not good.
In other words, I think the whole environment on the Arch is more
important than any single vendor's applications. Having said that,
if CC left the Acorn market, it would be a real blow. I've used
their app's since Wordwise and the Graphics ROM (WW was great,
the Graphics ROM initially seemed great, but compared very poorly
with Acorn's own GFX ROM that came out later). In that time I've
seen CC 'branch out' into the Atari ST market with Quill (a dismal
failure, apparently) and then return to the Acorn market.
: BUT... there is an interesting and not altogether subtle difference
: between the Acorn market and the PC market... and it may have something
: to do with the 1000 fold increase in customer base. The PC market is
: pretty cut-throat (as I'm sure you're aware) and although I hope Xara
: Studio challenges Corel (because it ought to) there hasn't been a
: fantastic track record in this department.
Actually, my take on the PC market is that the users are less
discerning. People usually buy PC's in the first place because 'everyone
else does', so most buyers are already pretty ignorant, being easily
swayed by whoever throws the most marketing dollars as them. Usually
Microsoft is the one with the most money, so their products get the most
buyers. And, because MS products sort of work, people are happy. I've
watched Word users labouring over changing styles or almost any WP
activity and commented on how difficult it is in Word. These people turn
to me with a blank look and ask how it could be any better.
CC are really up against it. It seems to be pretty irrelevant how good
your product is in the PC market. Just look at the PC! Let's not even
mention: DOS (vs. a whole range of better products from people like
Digital Research), Windows (vs. GEM, GEOS, etc.), Netware (vs. lots of
better systems), etc. Money counts, and CC doesn't have anywhere near
as much as the mastadons.
: All the best in the PC market
I second this. I would love to CC successful, because then, when any
of us are forced to use Windows, we would at least have access to
decent software.
: (A very brave decision... cf: "Yes Minister")
A courageous course.
-Malcolm. lit...@uslp.usl.com
Daniel Pead
i...@intrac.demon.co.uk (Ian Griffiths) writes:
> That would be Cairo wouldn't it? :-)
>
Well - there's a Paris, Texas etc. etc. etc. so I'd say there was at
least an evens chance of some little two-horse town in the US being
called Cairo :-)
Daniel Pead
> I do actually agree with your point I just think you chose the least
> appropriate example you could have done.
Well - I'd been Having Adventures with GDI at the time so I had
a few buzzwords to hand. I know that Camelot isn't using GDI and
I thought I'd made that clear. You could quote similar examples with
messages, dialogue boxes, the document/view architecture...
In any case - In addition to participating in the Game Of The Month - lets
flame CC - I was making a general point about portability of code.
--
Tim Browse
>
> In message <1995Mar3....@intrac.demon.co.uk> Ian Griffiths wrote:
>
>
> > I do actually agree with your point I just think you chose the least
> > appropriate example you could have done.
>
> Well - I'd been Having Adventures with GDI at the time so I had
> a few buzzwords to hand. I know that Camelot isn't using GDI and
> I thought I'd made that clear. You could quote similar examples with
> messages, dialogue boxes, the document/view architecture...
And the kernel code in Camelot is insulated from all of those things.
Philip Sainty
[ Olly wrote: ]
> > PS. My Pentium PC's arrived btw...Snowbarn in under a second :-))))
>
> I remember a chance letter from one of you lot in PCW which mentioned
> that Corel Draw did Snowbarn on a Pentium in 17 seconds...
> ...so by and large under one second is pretty healthy!
Could we please have some precise comparisons?
(eg. specifying which systems various times are achieved on - just
'Pentium' is a bit vague :)
Rik Heywood
> Did CC ever consider writing their own language and development
> evironment, making it freely available, and then using the various free
> ports of it to port Studio?
To create a useful language and development env. would have taken us
several years to do properly (and then there would be no real
guarantee that it would make it onto any other platforms).
Instead we picked a language that already existed on most platforms
(C++) and already had a very sophistcated development env. Since this
is now one of the more popular development envs. we thought it would
not be long before it arrived on the Archi.
James Lynn
>
> BTW, just out of interest: how much did Quill for the Atari ST contribute
> to Impression 1.0? Were there lots of ideas in Quill that found their
> true home in Impression?
You're probably thinking of the infamous Calligrapher. I've tried to
block out the memories of those dark days, but I think I'm safe in
saying that nothing in Impression came from Calligrapher. Calligrapher
was written by one person, and he left us well before we started on
Impression.
Jim.
j...@xara.co.uk
Malcolm Lithgow
Makes sense.
However, there are a lot of other alternatives, especially if you poke
around the net. C++ and its development environments are certainly more
widely commercialised than most other systems. This has its pro's and
con's. (Pro's being that commercial software typically has more support
behind it. However that seems to be changing a bit, what with things
like gcc, linux, and so forth gathering huge popular support.)
The reason I asked if CC considered producing there own dev. env. is
twofold: (1) C++ appears to be pretty pathetic, (2) CC has a history of
such extravagance (eg. the original Impulse project). Also, I would much
prefer to use a CC dev. env. than a Microsoft one. Oh well, one day
maybe?
-Malcolm. lit...@uslp.usl.com
Phil Martin
> BTW, just out of interest: how much did Quill for the Atari ST contribute
> to Impression 1.0? Were there lots of ideas in Quill that found their
> true home in Impression?
I think you're talking about what we knew as "Calligrapher" which
became "Quill" in some other lifetime after it had left us.
Calligrapher was a disaster for many reasons. One of those reasons
was that it didn't use any of CC's previous experience writing Word
Processors - so much of it was implemented "wrongly" from our
perspective. Thus none of the technology from Calligrapher ever got
near to Impression!
> Also, does anyone have any idea on the availability of Xara Studio.
Official line: "About two months"...
> (Will Impression get a 'load Studio file' option?)
Very doubtful.
> Did CC ever consider writing their own language and development
> evironment?
All the time! Although it's good fun doing that sort of thing and it
does result in tools that work *exactly* how you want them to, it's
simply not practical these days.
We've been down the "not invented here" road many times before,
writing linkers, debuggers, languages, even an OS once! We can
do it, and we can often do it better than anyone else, but it's
ultimately a waste of time. Why spend valuable time doing that when
there are other companies out there specialising in doing that job
and able to devote vast resources to it?
I think we've learnt now to ignore the temptations of these
interesting side-lines and to concentrate on what we do best!
(I hope!)
Phil 8-)
Phil Martin, Technical Manager, Xara Studio.
ph...@xara.co.uk
D I Simms
Yup. It seems whether Xara Studio gets converted is up to Acorn now. If they
produce the relevent libraries then we may well see it. I think CC would love
to produce a version, because they are attached to the Acorn market. It seems
that without the libraries and the c++ compiler it will cost them too much
money for the returned profit.
Kind regards
Dan Simms.
James Lynn
>
> [General comments about CC's chances in the PC market removed]
>
> In other words, I think the whole environment on the Arch is more
> important than any single vendor's applications. Having said that,
> if CC left the Acorn market, it would be a real blow. I've used
> their app's since Wordwise and the Graphics ROM (WW was great,
> the Graphics ROM initially seemed great, but compared very poorly
> with Acorn's own GFX ROM that came out later). In that time I've
> seen CC 'branch out' into the Atari ST market with Quill (a dismal
> failure, apparently) and then return to the Acorn market.
I should point out that Calligrapher (as it was called when we released
it) was our last product on the ST. Our first was FastBASIC which was
a long way from being a dismal failure.
You make it sound as if we scurried back to Acorn with our tails between
our legs. What actually happened was the ARM appeared, and suddenly
Acorn were at the cutting edge again.
As a company, we have the tendency to follow the technology that's most
fun, and as much as Acorn die-hards disbelieve it (and I was exactly the
same two years ago) PCs and Windows are fun. Different, but fun.
When Acorn bring out their 500 MIPS 64 bit superconducting ARM, I'm
sure we'll be happy to develop for that.
In C++.
Jim.
Disclaimer: All my own opinions.
Ben Summers
[big snip]
>
> When Acorn bring out their 500 MIPS 64 bit superconducting ARM, I'm
> sure we'll be happy to develop for that.
Jim! You shouldn't have said that - remember the NDA! Acorn will get
very annoyed if we tell everyone about their shortly-to-be-released
products...
Best wishes,
benjamin
----------------------------
Ben Summers
b...@cconcepts.co.uk
Although I may work there during the day, I type for myself, and not for CC.
"I don't like reality - I like mathematics..."
Alex Bligh
>
> Jeremy Bradley <bra...@cs.bris.ac.uk> wrote:
>
> [ Olly wrote: ]
> > > PS. My Pentium PC's arrived btw...Snowbarn in under a second :-))))
> >
> > I remember a chance letter from one of you lot in PCW which mentioned
> > that Corel Draw did Snowbarn on a Pentium in 17 seconds...
> > ...so by and large under one second is pretty healthy!
>
>
> Could we please have some precise comparisons?
Don't know about Tim's pentium, but at Windows user we could render
Snowbarn full screen at 800x600 on a 2 year old 16Mb Dell 486DX2-66 with
a standard 8 bit graphics card in 1.7 seconds without antialiasing,
2.4 seconds with antialiasing. The same file on Corel Draw took
about 45 seconds (of course without antialiasing). As far as RiscPCs
and ArtWorks go, I would guess on a similar set up in terms of screen
size and depth you'ld be looking at circa 7 seconds (this is a
guestimate).
All opinions are mine.
Alex
Tim Browse
>
> Philip Sainty <Philip...@comp.vuw.ac.nz> wrote:
> >
> > Jeremy Bradley <bra...@cs.bris.ac.uk> wrote:
> >
> > [ Olly wrote: ]
> > > > PS. My Pentium PC's arrived btw...Snowbarn in under a second :-))))
> > >
> > > I remember a chance letter from one of you lot in PCW which mentioned
> > > that Corel Draw did Snowbarn on a Pentium in 17 seconds...
> > > ...so by and large under one second is pretty healthy!
> >
> >
> > Could we please have some precise comparisons?
>
> Don't know about Tim's pentium, but at Windows user we could render
> Snowbarn full screen at 800x600 on a 2 year old 16Mb Dell 486DX2-66 with
> a standard 8 bit graphics card in 1.7 seconds without antialiasing,
My Pentium is 60MHz, has 8Mb of RAM, and has a local bus video card.
In the same screen resolution as Alex stated it rendered snowbarn
in about 0.8 - 0.95 seconds (without anti-aliasing). The local bus
video card is not very significant in this timing though. The main
advantage of that with Camelot is the push tool, which is very fast
because the blit is so fast. E.g. if anyone's familiar with the
sample ArtWorks clipart file of the Rolex, then moving that around
with the pushtool on my machine is like scrolling around a bitmap.
And Alex was right - ArtWorks takes about 7 seconds on a fast RPC,
given the same constraints.
Dave Cox
: James Lynn <j...@cconcepts.co.uk> wrote:
[Massive hack]
: > When Acorn bring out their 500 MIPS 64 bit superconducting ARM, I'm
: Jim! You shouldn't have said that - remember the NDA! Acorn will get
: very annoyed if we tell everyone about their shortly-to-be-released
: products...
I think dis-infomation is the name of the game here. Perhaps Acorn
should be starting rumours massively understating the gut-ripping
performance of the new machines.....oh they were,
I stand corrected! ;-)
--
Dave Cox email: cm2b...@bs47c.staffs.ac.uk
Who really hates Macs and Amigas.
D.J. Reeves
Malcolm Lithgow <lit...@summit.novell.com> wrote:
>The reason I asked if CC considered producing there own dev. env. is
>twofold: (1) C++ appears to be pretty pathetic, (2) CC has a history of
>such extravagance (eg. the original Impulse project). Also, I would much
>prefer to use a CC dev. env. than a Microsoft one. Oh well, one day
>maybe?
hmm, I don't really think our in-house debugging/profiling software we
have for the Archimedes really compares to Microsoft's Visual C++ one!
Although it does have the advantage that I can fit it all on a 360k
floppy...
Damian
Rik Heywood
>
> Rik Heywood (rhey...@xara.co.uk) wrote:
> : lit...@summit.novell.com (Malcolm Lithgow) wrote:
> : > Did CC ever consider writing their own language and development
> : > evironment, making it freely available, and then using the various free
> : > ports of it to port Studio?
>
> : To create a useful language and development env. would have taken us
>
> Makes sense.
>
> However, there are a lot of other alternatives, especially if you poke
> around the net. C++ and its development environments are certainly more
> widely commercialised than most other systems. This has its pro's and
> con's. (Pro's being that commercial software typically has more support
> behind it. However that seems to be changing a bit, what with things
> like gcc, linux, and so forth gathering huge popular support.)
>
> The reason I asked if CC considered producing there own dev. env. is
> twofold: (1) C++ appears to be pretty pathetic,
Or bloody poptastic as its also known.
> (2) CC has a history of
> such extravagance (eg. the original Impulse project).
ho hum... We did actually dream about it a bit....
Rik
Ben Jefferys
> You make it sound as if we scurried back to Acorn with our tails between
> our legs. What actually happened was the ARM appeared, and suddenly
> Acorn were at the cutting edge again.
>
> As a company, we have the tendency to follow the technology that's most
> fun, and as much as Acorn die-hards disbelieve it (and I was exactly the
^^^
> same two years ago) PCs and Windows are fun. Different, but fun.
^^^ ^^^
>
> When Acorn bring out their 500 MIPS 64 bit superconducting ARM, I'm
> sure we'll be happy to develop for that.
>
> In C++.
??????
That is possibly the most unbelievable remark I've heard from anybody at CC.
Replace "fun" with "lucrative", and we are probably nearer the truth.
CC have seen that the Acorn market is not as lucrative as it once was. They
are now running to Microsoft. With their tails between their legs.
And if Microsoft is now "cutting edge", I'd love to see what it is cutting
through...
Chris Mellor
>
> CC have seen that the Acorn market is not as lucrative as it once was. They
> are now running to Microsoft. With their tails between their legs.
>
> And if Microsoft is now "cutting edge", I'd love to see what it is cutting
> through...
>
Oh dear .... ummm.... Ben, I gotta take issue here. Business ain't religion.
Business is about mazoolah. And if the techies in a business think that
Microsoft's OS is fun and the Acorn one isn't that's their affair. If that
coincides with CC thinking that their SW is shit hot on the Arc and it looks
pretty good against Windows stuff too....well, hey...suppose we take on Corel
and the big boys? If our SW is really great then we get loadsamoney and have
fun too.
Microsoft's cutting edge around distributed objects seems pretty sharp. I see
their painful Windows evolution towards Windows 95 being the price of providing
backward compatibility with DOS and the 286 PC limits.
I also reckon Microsoft, with NT, could be cutting through high-priced business
Risc/Unix server systems.
Cheers.
(Anybody reckon Acorn users are like MG car buffs? Someday a better engine
will come!!!)
--
Chris Mellor
Garry
Ch...@pentire.demon.co.uk (Chris Mellor) wrote:
[Snip]
> Business is about mazoolah. And if the techies in a business think that
> Microsoft's OS is fun and the Acorn one isn't that's their affair. If that
> coincides with CC thinking that their SW is shit hot on the Arc and it looks
> pretty good against Windows stuff too....well, hey...suppose we take on
> Corel and the big boys?
This is all very true. Oddly, I deal regularly with companies that
forget why they are in business, two so far this year in receivership.
Shame really.
> If our SW is really great then we get loadsamoney and have
> fun too.
Will CC in the Acorn world survive being Xara in the PC world. Personally
I think not. Shame really.
Worth a try though.
--
Garry
G4FRO @ GB7IMB.#41.GBR.EU
ga...@goldhill.demon.co.uk
Ben Jefferys
Roight. I think the governing motive of CC is money. Too right. I agree - I'd
like to be as rich as Charles Moir seems to be. But to have the techies dress
this up in some sort of "we're just a bunch of enthusiasts really" guise is
silly. The techies program for Windows because the Accountants say its good
for them. No matter what the techies themselves think it's about.
What do you mean by "forget why they are in business"? Do you mean "to make
money" or "to make software"?
Ollie Cornes
> Roight. I think the governing motive of CC is money. Too right. I agree - I'd
> like to be as rich as Charles Moir seems to be. But to have the techies dress
> this up in some sort of "we're just a bunch of enthusiasts really" guise is
> silly. The techies program for Windows because the Accountants say its good
> for them. No matter what the techies themselves think it's about.
It's not silly. We're still human. We're still a small company.
Regards,
Ollie.
--
\ /\ Computer Concepts Ltd Xara Ltd
( ) ol...@cconcepts.co.uk ol...@xara.co.uk
.( o ). All opinions are mine
Tim Browse
>
> In article <19950402....@goldhill.demon.co.uk>, Garry wrote:
>
> >
> > Will CC in the Acorn world survive being Xara in the PC world. Personally
> > I think not. Shame really.
> >
> > Worth a try though.
> >
>
> like to be as rich as Charles Moir seems to be.
That's how businesses work. They make money. This means they can pay
their employees, and carry on being in business. It's quite simple.
There's a clue in the word 'business'. This doesn't mean that you
can't make money and enjoy your job at the same time.
> But to have the techies dress
> this up in some sort of "we're just a bunch of enthusiasts really" guise is
> silly. The techies program for Windows because the Accountants say its good
> for them. No matter what the techies themselves think it's about.
Is it so hard to believe that we like programming PCs? We like PCs,
as Jim said, because they're the fun technology at the moment. If
I didn't like programming PCs, I'd say so - don't worry about it.
> What do you mean by "forget why they are in business"? Do you mean "to make
> money" or "to make software"?
You'll never believe this, but it's both. We make money by making
software. Simple really.