Future reuse of code

[Harley]

Re: Future reuse of code


"goose" <ruse@webmail.c o.za> wrote in message
news:ff82ae1b.0 308150117.7098f 889@posting.goo gle.com...
| WB <su-news@bossi.com> wrote in message
news:<vxW_a.729 248$3C2.1702208 9@news3.calgary .shaw.ca>...
| > Roedy Green wrote:
| > > Don't be silly. Look at any C code designed to run on many platforms.
| > > It is riddled with macros to pull off the feat.
| > >
| > > You can do a few simple things like parse the command line, open a
| > > flat file in a platform independent way, but not even the size of int
| > > is guaranteed unless you play some games with macros.
| >
| > Well, no you can't open a file in a generic way. Opening a file on a PC
| > is different than opening a file on a mainframe. You need a special
| > library to do this:
| >
| > #ifdef I370
| > #include <lcio.h>
| > #endif
| >
| > Which works with the SAS C compiler.
| >
| > Plus, all your variables and function names need to be 8 characters or
| > less, AND mixed case is ignored, so VarA and VARA are the same, thanks
| > to the mainframe linker.
| >
| > At least it was a few years ago. Things may have chnaged since then....
|
| if it does not support fopen, it is not a std-compliant C hosted
| environment.
|
| goose

That's OK, you can write for the Z80, and ignore the mainframe.

[Richard Heathfield]

Re: Future reuse of code

[Followups set to comp.lang.c]

WB wrote:
[color=blue]
> Who said anything about fopen? You still use fopen, but MUST have the
> additional include file, which adds support for the mainframe way of
> doing things.[/color]

Then Get A Better Compiler. Both C/370 and LE370 support fopen correctly,
without any need for a different include file.
[color=blue]
> The mainframe C compiler is quite happy with long var names and mixed
> case.[/color]

/The/ mainframe C compiler? There are more things in heaven and earth,
Horatio, than are dreamt of in your philosophy.
[color=blue]
> I ended up writing a converter which takes the original C code, and
> converts it to something that will run on the mainframe. Yuck.[/color]

Got the tee-shirt.

--
Richard Heathfield : binary@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[docdwarf@panix.com]

Re: Future reuse of code

In article <bhh93e$c2b$1@t yfon.itea.ntnu. no>,
Bent C Dalager <bcd@pvv.ntnu.n o> wrote:[color=blue]
>In article <bhgma5$dhe$1@p anix1.panix.com >, <docdwarf@panix .com> wrote:[color=green]
>>In article <bhgj3v$1nq$1@t yfon.itea.ntnu. no>,
>>Bent C Dalager <bcd@pvv.ntnu.n o> wrote:[color=darkred]
>>>In article <bhg685$97i$1@p anix1.panix.com >, <docdwarf@panix .com> wrote:
>>>>
>>>>If the statements in question are the result of mere ignorance then they
>>>>lack the intentionality which is required of a lie... or am I missing
>>>>something ?
>>>
>>>You seem to be missing the fact that it was a flame. Logic and correct
>>>use of vocabulary are non-issues in that context.[/color]
>>
>>Ahhhh, *now* I understand... thanks greatly, you... you poopie-head, you!
>>
>>(did I do that right?)[/color]
>
>I certainly appreciate the effort, but you could do with some work on
>the execution :-)[/color]

All right... thanks greatly, you... you poopie-head, you! Now, off to the
gallows you go!

(was that a good enough execution?)

DD

[Mark Gordon]

Re: Future reuse of code

On Sat, 16 Aug 2003 10:42:52 GMT
"Harley" <dennis.harleyN oSpam@worldnet. att.net> wrote:
[color=blue]
>
> "goose" <ruse@webmail.c o.za> wrote in message
> news:ff82ae1b.0 308150117.7098f 889@posting.goo gle.com...
> | WB <su-news@bossi.com> wrote in message
> news:<vxW_a.729 248$3C2.1702208 9@news3.calgary .shaw.ca>...
> | > Roedy Green wrote:
> | > > Don't be silly. Look at any C code designed to run on many
> | > > platforms. It is riddled with macros to pull off the feat.
> | > >
> | > > You can do a few simple things like parse the command line, open
> | > > a flat file in a platform independent way, but not even the size
> | > > of int is guaranteed unless you play some games with macros.
> | >
> | > Well, no you can't open a file in a generic way. Opening a file on
> | > a PC is different than opening a file on a mainframe. You need a
> | > special library to do this:
> | >
> | > #ifdef I370
> | > #include <lcio.h>
> | > #endif
> | >
> | > Which works with the SAS C compiler.
> | >
> | > Plus, all your variables and function names need to be 8
> | > characters or less, AND mixed case is ignored, so VarA and VARA
> | > are the same, thanks to the mainframe linker.
> | >
> | > At least it was a few years ago. Things may have chnaged since
> | > then....
> |
> | if it does not support fopen, it is not a std-compliant C hosted
> | environment.
> |
> | goose
>
> That's OK, you can write for the Z80, and ignore the mainframe.[/color]

Do you have a fully conforming Java implementation for this mainframe?

Have you checked that there is not a conforming C implementation for
this mainframe? I just looked and GNU is working on an I370 port of gcc
so if nothing else is available that will be.
--
Mark Gordon

[Marco van de Voort]

Re: Future reuse of code

In article <20030815232224 .1f0da19d.spamt rap@flash-gordon.me.uk>, Mark Gordon wrote:[color=blue]
> On Fri, 15 Aug 2003 14:27:31 +0000 (UTC)
> Marco van de Voort <marcov@stack.n l> wrote:[color=green][color=darkred]
>> > I've not done C++,[/color]
>>
>> Only a bit. (pretty much the amount needed for Delphi compability.
>> Basic classes and such)
>>[color=darkred]
>> > but I have done Pascal (had to use non-portable
>> > features)[/color]
>>
>> Like?[/color]
>
> Trapping the "STOP" key on an HP workstation. Only used this on the HP.
>
> Separately compiled files (has that been added to the standard?) Handled
> differently on the different Pascal implementations I used.[/color]

Extended Pascal standard has a module concept. Borland Pascal's (which branched
inbetween the standards) have something similar with "unit" as such.
[color=blue]
> A non-standard way to access third party libraries. Handled differently
> on the different Pascal implementations I used.[/color]

Ok, you mean portable between compilers. Most dialects died out or converge
(usually towards the ansi standards). The only remaining are the Borland dialects
(BP/TP, Delphi and compatibles like FPC, VP) and the ansi standard.

While the avg BP/TP and Delphi code aren't very portable (in the same way
the avg VC++ code isn't very portable), the vast majority maps onto similar
C constructs, the rest can be considered platform dependant extensions (stuff for
dlls etc), just like e.g. VC.

I've Delphi code (compiled using FPC) on PPC and m68k systems.
[color=blue]
> Probably a number of other things that I can't remember now.[/color]
[color=blue]
> I think the Delphi diverged even further, although I helped people with
> Delphi rather than using it myself.[/color]

Yes. It is more C++ than C. It includes the older dialect, but is an OOP language
on top of that.

[JC]

Re: 4Re: Future reuse of code

Peter E. C. Dashwood <dashwood@enter net.co.nz> wrote in message
news:b3638c46.0 308161511.d8dda 7@posting.googl e.com...[color=blue]
>
> I have little to add.
>
> You say you're angry. So was I. I'm tired of your cheap shots.
>
> I suggest the best policy for both of us is to simply ignore each
> others' posts.
>
> Please don't quote or respond to my mail in your posts, and I'll adopt
> the same policy with yours.
>[/color]

Hollerith Cards at dawn??

[Mark Gordon]

Re: Future reuse of code

On Sun, 17 Aug 2003 00:20:27 +0000 (UTC)
Marco van de Voort <marcov@stack.n l> wrote:
[color=blue]
> In article <20030815232224 .1f0da19d.spamt rap@flash-gordon.me.uk>, Mark
> Gordon wrote:[color=green]
> > On Fri, 15 Aug 2003 14:27:31 +0000 (UTC)
> > Marco van de Voort <marcov@stack.n l> wrote:[color=darkred]
> >> > I've not done C++,
> >>
> >> Only a bit. (pretty much the amount needed for Delphi compability.
> >> Basic classes and such)
> >>
> >> > but I have done Pascal (had to use non-portable
> >> > features)
> >>
> >> Like?[/color]
> >
> > Trapping the "STOP" key on an HP workstation. Only used this on the
> > HP.
> >
> > Separately compiled files (has that been added to the standard?)
> > Handled differently on the different Pascal implementations I used.[/color]
>
> Extended Pascal standard has a module concept. Borland Pascal's (which
> branched inbetween the standards) have something similar with "unit"
> as such.[/color]

That may be, but since *every* Pascal variant I used provided a
different mechanism it is safe to assume _at_most_ one of them was
standard.
[color=blue][color=green]
> > A non-standard way to access third party libraries. Handled
> > differently on the different Pascal implementations I used.[/color]
>
> Ok, you mean portable between compilers. Most dialects died out or
> converge(usuall y towards the ansi standards). The only remaining are
> the Borland dialects(BP/TP, Delphi and compatibles like FPC, VP) and
> the ansi standard.[/color]

I know of a lot of embedded code written in Tectronics Pascal that will
have to be maintained for at least the next 15 years. The compiler may
not be under development, but the language is hardly dead. The same
applies to HP Pascal. 3 years ago the BSO Pascal code I wrote was also
still in use.
[color=blue]
> While the avg BP/TP and Delphi code aren't very portable (in the same
> way the avg VC++ code isn't very portable), the vast majority maps
> onto similar C constructs, the rest can be considered platform
> dependant extensions (stuff for dlls etc), just like e.g. VC.
>
> I've Delphi code (compiled using FPC) on PPC and m68k systems.[/color]

The problem is that if Delphi does not follow the ANSI conventions for
seperate compilation of modules then you can't easily include an ANSI
Pascal module in a Delphi project. You can, on the other hand, include
an ANSI C++ module in a VC++ project.
[color=blue][color=green]
> > Probably a number of other things that I can't remember now.[/color]
>[color=green]
> > I think the Delphi diverged even further, although I helped people
> > with Delphi rather than using it myself.[/color]
>
> Yes. It is more C++ than C. It includes the older dialect, but is an
> OOP language on top of that.[/color]

I know what Delphi is, I just don't know how far the ANSI Pascal
standard went, since I *never* used a Pascal compiler claiming ANSI
conformance despite using several Pascal variants.

So my experience of Pascal is one of a heavily extended language with
major incompatibiliti es between variants. If there are *now* ANSI Pascal
compilers for most targets and a way to easily mix Delphi and ANSI
Pascal then things have changed.
--
Mark Gordon

[Marco van de Voort]

Re: Future reuse of code

In article <20030817125618 .4fe1d8ee.spamt rap@flash-gordon.me.uk>, Mark Gordon wrote:[color=blue]
> On Sun, 17 Aug 2003 00:20:27 +0000 (UTC)
> Marco van de Voort <marcov@stack.n l> wrote:
>[color=green][color=darkred]
>> >
>> > Trapping the "STOP" key on an HP workstation. Only used this on the
>> > HP.
>> >
>> > Separately compiled files (has that been added to the standard?)
>> > Handled differently on the different Pascal implementations I used.[/color]
>>
>> Extended Pascal standard has a module concept. Borland Pascal's (which
>> branched inbetween the standards) have something similar with "unit"
>> as such.[/color]
>
> That may be, but since *every* Pascal variant I used provided a
> different mechanism it is safe to assume _at_most_ one of them was
> standard.[/color]

That's possible.
[color=blue][color=green][color=darkred]
>> > A non-standard way to access third party libraries. Handled
>> > differently on the different Pascal implementations I used.[/color]
>>
>> Ok, you mean portable between compilers. Most dialects died out or
>> converge(usuall y towards the ansi standards). The only remaining are
>> the Borland dialects(BP/TP, Delphi and compatibles like FPC, VP) and
>> the ansi standard.[/color]
>
> I know of a lot of embedded code written in Tectronics Pascal that will
> have to be maintained for at least the next 15 years. The compiler may
> not be under development, but the language is hardly dead. The same
> applies to HP Pascal. 3 years ago the BSO Pascal code I wrote was also
> still in use.[/color]

Sure, but that is the case with all kinds of embedded C's too. Except for
x86, the only other processors I programmed for ( a 68k variant and Hitachi
8051 variant) were also not fully ansi C conforming.

The fact is that the bulk of new pascal development is either in ansi or
borland dialects. (a loose guestimate is ratio 1:100). There are deviate
dialects in circulation, specially in the embedded world, but which older
language doesn't have that?
[color=blue][color=green]
>> While the avg BP/TP and Delphi code aren't very portable (in the same
>> way the avg VC++ code isn't very portable), the vast majority maps
>> onto similar C constructs, the rest can be considered platform
>> dependant extensions (stuff for dlls etc), just like e.g. VC.
>>
>> I've Delphi code (compiled using FPC) on PPC and m68k systems.[/color]
>
> The problem is that if Delphi does not follow the ANSI conventions for
> seperate compilation of modules then you can't easily include an ANSI
> Pascal module in a Delphi project.[/color]

Yes, and that makes the ansi world and the Borland world pretty much separate
communities (read nearly two languages). There are some that try to bridge the
gap like GNU Pascal (a compiler that supports both BP an ansi, and is working on later
borland dialects like Delphi)

But in general the picture you sketch is no problem since the Delphi
community, codebase etc is at least a magnitude 100 larger than the
ansi-pascal community.
[color=blue]
> You can, on the other hand, include
> an ANSI C++ module in a VC++ project.[/color]

You can't use it in C51 :_)

But the real trouble is a C centric view, that puts the standard
automatically in the middle. A standard is a tool to obtain some
unification, not a purpose in itself. Sometimes it works (as in the C case),
sometimes it doesn't succeed in unifying the separate dialects (as in
Pascal)

The situation you mention above is simply no problem. If one uses Delphi,
on can access the largest codebase by far (which is Borland dialects).
[color=blue][color=green][color=darkred]
>> > Probably a number of other things that I can't remember now.[/color]
>>[color=darkred]
>> > I think the Delphi diverged even further, although I helped people
>> > with Delphi rather than using it myself.[/color]
>>
>> Yes. It is more C++ than C. It includes the older dialect, but is an
>> OOP language on top of that.[/color]
>
> I know what Delphi is, I just don't know how far the ANSI Pascal
> standard went, since I *never* used a Pascal compiler claiming ANSI
> conformance despite using several Pascal variants.[/color]

There are two standards and one draft that was never turned into a standard.

The draft being OOP orientated (Object Pascal) in nature and sponsored by
Apple IIRC, was used (but not strictly followed) by Borland too, to create Delphi.
[color=blue]
> So my experience of Pascal is one of a heavily extended language with
> major incompatibiliti es between variants.[/color]

I used three C/C++ compilers. VC++, Keile C51 and gcc on FreeBSD. All codebases were
pretty uncompilable on the compilers they were not written for, because of extensions,
libraries etc.

IOW I don't see a fundamental difference. True, the number of language
variants, and the average number of extensions etc are a bit less in the C
case, but that is more the language popularity.

With both languages carefully crafted codebases are somewhat portable, but
in both cases the subset is too limiting. (ansi C+posix is already a bit
better, but that is more than a mere language standard, and it still sucks
on Windows)
[color=blue]
> If there are *now* ANSI Pascal compilers for most targets and a way to
> easily mix Delphi and ANSI Pascal then things have changed.[/color]

Delphi and Ansi Pascal are not really mixable, except on the most minimal
level. Pretty much like VC++ and Keile C51.

[Scott Moore]

Re: Designing Components : WAS - Re: Re: Future reuse of code

Please STOP crossposting to comp.lang.pasca l.ansi-iso. This thread
has nothing to do with that forum.

Thank you.

[Marco van de Voort]

Re: Future reuse of code

In article <20030817202235 .42748866.spamt rap@flash-gordon.me.uk>, Mark Gordon wrote:[color=blue]
> On Sun, 17 Aug 2003 14:03:37 +0000 (UTC)
> Marco van de Voort <marcov@stack.n l> wrote:[/color]
[color=blue][color=green][color=darkred]
>> > compiler may not be under development, but the language is hardly
>> > dead. The same applies to HP Pascal. 3 years ago the BSO Pascal code
>> > I wrote was also still in use.[/color]
>>
>> Sure, but that is the case with all kinds of embedded C's too.[/color]
>
> The HP Pascal I mentioned was *not* an embedded Pascal.[/color]

Neither is VC++, or BC.
[color=blue]
> Anyway, as far as I'm aware all C implementations support the same
> mechanism for separate compilation of modules so you don't have the same
> problem.[/color]

Hmm. Prototypes etc? Afaik K&R had no modules or prototypes at all, the
separate compilation were just externals, and parameters didn't even had
to match. (iow everything happened on linker, not langauge level)
[color=blue][color=green]
>> Except
>> for x86, the only other processors I programmed for ( a 68k variant
>> and Hitachi 8051 variant) were also not fully ansi C conforming.[/color]
>
> The Texas Instruments implementation of C for the TMS320C1x/2X/5X was a
> fully conforming implementation and even came with a copy of K&R2 as
> part of the documentation set. This was at the same time I was dealing
> with all those different Pascals...[/color]

K&R is no standard. ANSI is.
[color=blue][color=green]
>> The fact is that the bulk of new pascal development is either in ansi
>> or borland dialects. (a loose guestimate is ratio 1:100). There are
>> deviate dialects in circulation, specially in the embedded world, but[/color][/color]
~>> which older language doesn't have that?[color=blue]
>
> Pascal is IMHO worse because the original definition did not include
> support for separate compilation of modules. For this reason (and
> probably others) K&R C is more likely to compile on a modern compiler
> that supports ANSI C than Pascal written for any of the compilers I
> mentioned.[/color]

That's not true afaik (but I'm no expert, just from the old BSD days). Most
K&R code mismatches or omits parameters between declaration and compilation.
This was only fixed with the formal prototypes in some later standard.
[color=blue]
> This is irrespective of whether it was embedded or
> non-embedded C or Pascal.[/color]

Embedded versions are often simplified, and therefore often base
on older versions. Judging the state of Pascal by those is a bit odd.
[color=blue][color=green][color=darkred]
>> >> VC.
>> >> I've Delphi code (compiled using FPC) on PPC and m68k systems.
>> >
>> > The problem is that if Delphi does not follow the ANSI conventions
>> > for seperate compilation of modules then you can't easily include an
>> > ANSI Pascal module in a Delphi project.[/color]
>> ~
>> Yes, and that makes the ansi world and the Borland world pretty much
>> separate communities (read nearly two languages).[/color]
>
> C & C++ are two distinct languages, yet you can link them relatively
> easily...[/color]

C++ nearly includes C, even though they are formally separate languages.

Link compability is a compiler/linker thing anyway though, and has not much
to do with the language. At least if the language wants to remain portable :-)
You probably mean that C++ and C FROM THE SAME VENDOR reasonably link well.

OTOH that is not a problem. Most Pascal compilers also link to C. They
probably also can link to eachother, only on a deeper level (directly
passing file handles instead of file descriptors etc)
[color=blue][color=green]
>> BP an ansi, and is working on later borland dialects like Delphi)
>>
>> But in general the picture you sketch is no problem since the Delphi
>> community, codebase etc is at least a magnitude 100 larger than the
>> ansi-pascal community.[/color]
>
> So ANSI Pascal is largely irrelevant to the Pascal community ;-)[/color]

In practice yes. But the Borland group, while it far outnumbers ANSI, is
x86 (and often even x86/win32) centric. So if you go outside x86, you'll
encounter quite a lot of ansi.
[color=blue][color=green][color=darkred]
>> > an ANSI C++ module in a VC++ project.[/color]
>>
>> You can't use it in C51 :_)[/color]
>
> I bet you can use a lot of conforming C code not written for the 8051 on
> an 8051, since I bet there is a conforming implementation.[/color]

Maybe, but that would really strain those 256 bytes of memory.
[color=blue][color=green]
>> But the real trouble is a C centric view, that puts the standard
>> automatically in the middle. A standard is a tool to obtain some
>> unification, not a purpose in itself. Sometimes it works (as in the C
>> case), sometimes it doesn't succeed in unifying the separate dialects
>> (as in Pascal)[/color]
>
> I don't know about anyone else here, but I use the standard as a way of
> ensuring that my code will run on multiple platforms with minimal
> difficulty (I do have to use platform specific extensions in limited
> areas) and not as an end in itself.[/color]

Yes. It is a very limited help of trying to verify that. But in practice,
the standard is often not enough to build an average application.
[color=blue][color=green]
>> The situation you mention above is simply no problem. If one uses
>> Delphi, on can access the largest codebase by far (which is Borland
>> dialects).[/color]
>
> In C you can access most of the C code base whether it was originally
> targeted for embedded or hosted environments. Obviously on an embedded
> environment without a file system you can't use file oriented libraries,
> but you could use some MD5 code written for a PC.[/color]

Quite a lot of code isn't very conforming (I can remember having to fix
nearly every program when I got an Alpha machine)

But except for that (and those original K&R code), you are somewhat right,
the problem is mroe that a fully standard C program is often trivial, and
no real app.

Something like that is nice to show to students, but not something for IRL.

But that doesn't mean (and I don't mean to imply) that the standard is
useless, on the contrary, I think the C situation *is* better.
I do think however the magnitude of the differences (specially when related
to standards) is severely overrated.
[color=blue][color=green][color=darkred]
>> > I know what Delphi is, I just don't know how far the ANSI Pascal
>> > standard went, since I *never* used a Pascal compiler claiming ANSI
>> > conformance despite using several Pascal variants.[/color]
>>
>> There are two standards and one draft that was never turned into a
>> standard.[/color]
>
> So do the majority of modern Pascal implementations support ANSI
> standard Pascal?[/color]

Either that or Borland. Borland is proprietary, but so dominant that smaller
vendors (TMT,VP) follow it, and it also has following in the open source
community.
[color=blue][color=green]
>> I used three C/C++ compilers. VC++, Keile C51 and gcc on FreeBSD. All
>> codebases were pretty uncompilable on the compilers they were not
>> written for, because of extensions, libraries etc.[/color]
>
> Both VC++ and gcc can compile ANSI standard C (I don't know Keile C51)
> so as long as you keep your implementation specific code isolated[/color]

Sure, but that was not what I said. I said the compilers can't compile
an average program from the other.
[color=blue]
> (sometime I always try to do) then the bulk of your code will compile
> and run correctly on both.[/color]

And be fairly trivial.
[color=blue][color=green]
>> IOW I don't see a fundamental difference. True, the number of language
>> variants, and the average number of extensions etc are a bit less in
>> the C case, but that is more the language popularity.[/color]
>
> One major difference, almost all C compilers produced for a long time
> have been able to compile ANSI standard C, I don't think the same can be
> said about Pascal.[/color]

No, and probably never will. I don't dispute that. I'm just saying it is
overrated.
[color=blue][color=green]
>> With both languages carefully crafted codebases are somewhat portable,
>> but in both cases the subset is too limiting.[/color]
>
> My experience was that *no* Pascal module compile on any compiler other
> than the one it was written on because it would fail as soon as you
> reached the line indicating it was a module rather than a program or as
> soon as it referenced any other module, whichever came first.[/color]

Well, that is not my experience. The borland versions (generations is a
better world) are backward compatible till 1985, and ansi pascal is pretty
close to compability with even J&W pascal.
[color=blue][color=green]
>> (ansi C+posix is already
>> a bit better, but that is more than a mere language standard, and it
>> still sucks on Windows)[/color]
>
> Windows has Posix compatibility layers, depending on what you want.[/color]

Sure. But that is not ansi isn't it?
[color=blue]
> also has GTK available if you want a common graphics handling code
> between Windows and Unix.[/color]

(GTK on windows sucks, but)

GTK is also not exclusive to C. Actually the RAD of the pascal compiler I use
uses GTK on Unix platforms (but native winapi on win32)

Delphi does something similar, but uses QT.
[color=blue][color=green][color=darkred]
>> > If there are *now* ANSI Pascal compilers for most targets and a way
>> > to easily mix Delphi and ANSI Pascal then things have changed.[/color]
>>
>> Delphi and Ansi Pascal are not really mixable, except on the most
>> minimal level. Pretty much like VC++ and Keile C51.[/color]
>
> As I say, I don't know Kiele, but it is possible to have code that can
> be compiled by both VC++ and gcc. Look at Berkeley DB for one example.[/color]

I can also craft Pascal code accepted by (nearly?) every compiler, so what's
the difference?

(well, there actually is. The string handling of that code
will be clumsy. char ident[x] based like C, and that is not how you use
strings usually under Pascal)

[Joe Zitzelberger]

Re: Future reuse of code

In article <20030812135022 .586618b0.spamt rap@flash-gordon.me.uk>,
Mark Gordon <spamtrap@fla sh-gordon.me.uk> wrote:
[color=blue]
> On Tue, 12 Aug 2003 07:57:18 -0400
> Joe Zitzelberger <joe_zitzelberg er@nospam.com> wrote:
>[color=green]
> > In article <ff82ae1b.03081 20009.43157fcf@ posting.google. com>,
> > ruse@webmail.co .za (goose) wrote:
> >[color=darkred]
> > > and yet creating a std C program would not only get you that, it
> > > would also get you a fairly snappy application *and* leave you open
> > > in the future to be able to support those people who have machines
> > > that are not capable of running java (certain designer
> > > palmtop-types) to *also* interface with the campus machines.
> > >
> > > java doesn't *buy* you anything extra in terms of portability.
> > > The only relatively *portable* way I can think of is when writing
> > > applets for web-pages (note: /relatively/). as long as the browser
> > > has a java runtime environment, of course.
> > >
> > > Java does have its advantages. Portability isn't one of them.[/color]
> >
> > ???Huh???
> >
> > Which sort of Java isn't portable? I get binary compatibility on all
> > desktop/server/enterprise machines and many embedded as well. If that
> > fails (it never has) I get source level compatibilily (the compiler is
> > written in java after all...) across all the platforms.
> >
> > Now it might not make any sense for me to try and open a dialog box on
> > a stoplight, and the stoplight manufacturer might well leave those
> > libraries out, but that hardly makes it non-portable.[/color]
>
> What if the JVM has not been ported to the processor you are using? Can
> you find a JVM for any of the following processors?
>
> Z80
> 6502
> 8051
> TMS320Cxx
>
> just to name 4 families of processor off the top of my head all of which
> are used in *current* projects.
>
> Even if you ported the JVM it would run like a snail on tranquilisers.[/color]

I used the Pascal byte code system, precursor and work-alike to modern
Java, on the 6502 and Z80. And yes, it did run like a snail on
tranquilisers. For that matter, so did highly tuned assembler and
compiled C.

Anyone who wants to license a reference implementation from Sun can do
so for $150,000, IIRC, and write a very think hardware layer to get Java
on thier chip/os.

There are also clean room clones available...
[color=blue]
> Also we had to upgrade from SCO 5.0.5 to SCO 5.0.6, something I'm told
> was painful, on several customer sites in order to be able to run a
> specific Java application. Java 1.4 is not available for earlier version
> of SCO and was not available at that time for AIX, which another of our
> customers uses.[/color]

I've not played with SCO for a while (1997 to be exact), but a minor
release ought not prevent you from running Java 1.4? What happened when
you installed it on 5.0.5?

[color=blue][color=green]
> > All of this talks of applications, not applets which were a cute, but
> > useless toy.[/color]
>
> As have the people talking about processors where the JVM is not
> available.[/color]

A brief search of Google shows at least one JVM product targeted at the
6502, specifically C64, from mts.com. And a JIT compiler/runtime
targeted at Z80/6502 from Stanford. Also a hardware boost for th
6502/65816 family from Fawcett.

That is the first results page. I'm not sure what any of the statuses
are.

[color=blue][color=green]
> > Have you ever actually tried porting an application to another
> > hardware/os using std C? It is not just a recompile, there are plenty
> > of issues the original programmers must have planned for -- and they
> > usually don't.[/color]
>
> One program I wrote in C for an embedded system was debugged by me on a
> Silocon Graphics workstation by running the code natively (not in an
> emulator or simulator). All I had to do was replace the two functions
> that talked to the hardware with one function to read test data and
> another to interface to a graphics library and display the results.
> The debugged code then ran perfectly on the embedded system without any
> further changes.
>
> Some companies actually hold code reviews to ensure that code is well
> written, and obstreperous abstrads like be *do* reject code and insist
> on it being rewritten if the job has not been done properly.[/color]

I think that is a great approach, but I also think it is a rarity to
have such reviews held. In my experience, "portabilit y" usually means
running on all versions of Windows, or, at a streach, all versions of
Windows and some Linux. Something as trivial as endianess (because the
whole world really runs on Intel, doesn't it) is almost universally not
considered.

[Alan Balmer]

Re: Designing Components : WAS - Re: Re: Future reuse of code

On Sun, 17 Aug 2003 22:53:38 GMT, "James J. Gavan" <jjgavan@shaw.c a>
wrote:
[color=blue]
>If we don't hear from each language, may we assume that particular language
>doesn't have all the necessary tools ???? <G>[/color]

No, but you could assume not everyone wants to play your game.

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[James J. Gavan]

Re: Designing Components : WAS - Re: Re: Future reuse of code



Alan Balmer wrote:
[color=blue]
> On Sun, 17 Aug 2003 22:53:38 GMT, "James J. Gavan" <jjgavan@shaw.c a>
> wrote:
>[color=green]
> >If we don't hear from each language, may we assume that particular language
> >doesn't have all the necessary tools ???? <G>[/color]
>
> No, but you could assume not everyone wants to play your game.
>[/color]

Why assume a game was being played ? It was a legit question, what techniques do
you use within your language to handle such a problem - I'm not 'voting' for one
outcome - a genuine enquiry as to how OO programmers would handle such, from the
features they have in their respective languages.

Please don't read into the message an alternative meaning. (If I had a hidden
agenda, be damned sure I would have asked the question in a very different
fashion).

Jimmy

[Mark Gordon]

Re: Future reuse of code

On Mon, 18 Aug 2003 08:23:27 +0000 (UTC)
Marco van de Voort <marcov@stack.n l> wrote:
[color=blue]
> In article <20030817202235 .42748866.spamt rap@flash-gordon.me.uk>, Mark
> Gordon wrote:[color=green]
> > On Sun, 17 Aug 2003 14:03:37 +0000 (UTC)
> > Marco van de Voort <marcov@stack.n l> wrote:[/color]
>[color=green][color=darkred]
> >> > compiler may not be under development, but the language is hardly
> >> > dead. The same applies to HP Pascal. 3 years ago the BSO Pascal
> >> > code I wrote was also still in use.
> >>
> >> Sure, but that is the case with all kinds of embedded C's too.[/color]
> >
> > The HP Pascal I mentioned was *not* an embedded Pascal.[/color]
>
> Neither is VC++, or BC.[/color]

Both VC++ nor BC (if you mean what I think you mean) *can* compile ANSI
C, so they support my point.
[color=blue][color=green]
> > Anyway, as far as I'm aware all C implementations support the same
> > mechanism for separate compilation of modules so you don't have the
> > same problem.[/color]
>
> Hmm. Prototypes etc? Afaik K&R had no modules or prototypes at all,
> the separate compilation were just externals, and parameters didn't
> even had to match. (iow everything happened on linker, not langauge
> level)[/color]

K&R did not have prototypes, however the specification *did* allow for
the separate compilation of modules. That was standardised by C89.
However the language *did* specify that you could compile separate
modules (even having an extern keyword for specifying that an object
was external). It just does not specify how you invoke *any* of the
tools.

The original definition of Pascal did *not* specify any support separate
modules and provided no mechanism for specifying that an object was
external, so any support for separate compilation of modules was an
extension.
[color=blue][color=green][color=darkred]
> >> Except
> >> for x86, the only other processors I programmed for ( a 68k variant
> >> and Hitachi 8051 variant) were also not fully ansi C conforming.[/color]
> >
> > The Texas Instruments implementation of C for the TMS320C1x/2X/5X
> > was a fully conforming implementation and even came with a copy of
> > K&R2 as part of the documentation set. This was at the same time I
> > was dealing with all those different Pascals...[/color]
>
> K&R is no standard. ANSI is.[/color]

The second edition (K&R2) is for ANSI standard C and is one of the most
commonly used and recommended reference books for it.
[color=blue][color=green][color=darkred]
> >> The fact is that the bulk of new pascal development is either in
> >> ansi or borland dialects. (a loose guestimate is ratio 1:100).
> >> There are deviate dialects in circulation, specially in the
> >> embedded world, but
> >> which older language doesn't have that?[/color]
> >
> > Pascal is IMHO worse because the original definition did not include
> > support for separate compilation of modules. For this reason (and
> > probably others) K&R C is more likely to compile on a modern
> > compiler that supports ANSI C than Pascal written for any of the
> > compilers I mentioned.[/color]
>
> That's not true afaik (but I'm no expert, just from the old BSD days).
> Most K&R code mismatches or omits parameters between declaration and
> compilation. This was only fixed with the formal prototypes in some
> later standard.[/color]

Prototypes were added with the ansi standard, but
extern int foo();
extern int bar;
were valid ways of declaring function foo() and variable bar without
defining them, thus allowing them to be defined in another module. The
original definition of Pascal had no such feature.
[color=blue][color=green]
> > This is irrespective of whether it was embedded or
> > non-embedded C or Pascal.[/color]
>
> Embedded versions are often simplified, and therefore often base
> on older versions. Judging the state of Pascal by those is a bit odd.[/color]

All the embedded C compilers I have used implemented the full
specification for a free-standing implementation. All of the Pascals,
including those that were *not* targeting embedded systems, used
non-standard, non-portable mechanisms for allowing access to symbols
defined in separately compiled modules.
[color=blue][color=green][color=darkred]
> >> >> VC.
> >> >> I've Delphi code (compiled using FPC) on PPC and m68k systems.
> >> >
> >> > The problem is that if Delphi does not follow the ANSI
> >> > conventions for seperate compilation of modules then you can't
> >> > easily include an ANSI Pascal module in a Delphi project.
> >> ~
> >> Yes, and that makes the ansi world and the Borland world pretty
> >> much separate communities (read nearly two languages).[/color]
> >
> > C & C++ are two distinct languages, yet you can link them relatively
> > easily...[/color]
>
> C++ nearly includes C, even though they are formally separate
> languages.[/color]

No, C++ will report diagnostics and probably abort compilation when
trying to compile a *lot* of ANSI standard C. For example, if the result
of a malloc call is not cast C++ will reject it where as not casting it
is the recommended approach in C.
[color=blue]
> Link compability is a compiler/linker thing anyway though, and has not
> much to do with the language. At least if the language wants to remain
> portable :-) You probably mean that C++ and C FROM THE SAME VENDOR
> reasonably link well.[/color]

The C++ standard explicitly defines some of how the linking of C and C++
is to be handled, such as the 'extern "C"' stuff you see in a lot of
headers. The C standard cooperates to the extend of guaranteeing a way
of identifying at compile time whether a file is being compiled as C or
C++ to allow you to share header files.
[color=blue]
> OTOH that is not a problem. Most Pascal compilers also link to C. They
> probably also can link to eachother, only on a deeper level (directly
> passing file handles instead of file descriptors etc)[/color]

However, there is no way defined to specify that external objects are
external C objects, unlike with C++. There is also no way to include a C
header file from a Pascal source file.
[color=blue][color=green][color=darkred]
> >> BP an ansi, and is working on later borland dialects like Delphi)
> >>
> >> But in general the picture you sketch is no problem since the
> >> Delphi community, codebase etc is at least a magnitude 100 larger
> >> than the ansi-pascal community.[/color]
> >
> > So ANSI Pascal is largely irrelevant to the Pascal community ;-)[/color]
>
> In practice yes. But the Borland group, while it far outnumbers ANSI,
> is x86 (and often even x86/win32) centric. So if you go outside x86,
> you'll encounter quite a lot of ansi.[/color]

Whatever processor you will find a lot of ANSI standard C, even for the
x86/DOS/Win world.
[color=blue][color=green][color=darkred]
> >> > an ANSI C++ module in a VC++ project.
> >>
> >> You can't use it in C51 :_)[/color]
> >
> > I bet you can use a lot of conforming C code not written for the
> > 8051 on an 8051, since I bet there is a conforming implementation.[/color]
>
> Maybe, but that would really strain those 256 bytes of memory.[/color]

I just checked, and version 7 of C51 claims ANSI conformance.
[color=blue][color=green][color=darkred]
> >> But the real trouble is a C centric view, that puts the standard
> >> automatically in the middle. A standard is a tool to obtain some
> >> unification, not a purpose in itself. Sometimes it works (as in the
> >> C case), sometimes it doesn't succeed in unifying the separate
> >> dialects (as in Pascal)[/color]
> >
> > I don't know about anyone else here, but I use the standard as a way
> > of ensuring that my code will run on multiple platforms with minimal
> > difficulty (I do have to use platform specific extensions in limited
> > areas) and not as an end in itself.[/color]
>
> Yes. It is a very limited help of trying to verify that. But in
> practice, the standard is often not enough to build an average
> application.[/color]

I've written large C applications for real world problems as part of my
job where only a small amount of isolated code was implementation
dependant.

As part of my current job I work on an application with a few hundred
thousand lines of code which are slowly being migrated from K&R C to
ANSI standard C whilst also being maintained and further developments
done. The bulk of the implementation specifics are in a separate library
allowing *all* of the business logic to be written in either K&R C (for
the old stuff) or standard C89 for the new stuff. So that is probably a
few hundred thousand lines of C that will eventually all be written to
C98 and a *much* smaller amount of implementation specific code which
is steadily shrinking as we do a progressive rewrite.
[color=blue][color=green][color=darkred]
> >> The situation you mention above is simply no problem. If one uses
> >> Delphi, on can access the largest codebase by far (which is Borland
> >> dialects).[/color]
> >
> > In C you can access most of the C code base whether it was
> > originally targeted for embedded or hosted environments. Obviously
> > on an embedded environment without a file system you can't use file
> > oriented libraries, but you could use some MD5 code written for a
> > PC.[/color]
>
> Quite a lot of code isn't very conforming (I can remember having to
> fix nearly every program when I got an Alpha machine)
>
> But except for that (and those original K&R code), you are somewhat
> right, the problem is mroe that a fully standard C program is often
> trivial, and no real app.
>
> Something like that is nice to show to students, but not something for
> IRL.[/color]

As I say, I work on large *real* applications using standard C for 90%
(or more) of my work. Therefor it is useful for *real* work on *large*
projects.
[color=blue]
> But that doesn't mean (and I don't mean to imply) that the standard is
> useless, on the contrary, I think the C situation *is* better.
> I do think however the magnitude of the differences (specially when
> related to standards) is severely overrated.
>[color=green][color=darkred]
> >> > I know what Delphi is, I just don't know how far the ANSI Pascal
> >> > standard went, since I *never* used a Pascal compiler claiming
> >> > ANSI conformance despite using several Pascal variants.
> >>
> >> There are two standards and one draft that was never turned into a
> >> standard.[/color]
> >
> > So do the majority of modern Pascal implementations support ANSI
> > standard Pascal?[/color]
>
> Either that or Borland. Borland is proprietary, but so dominant that
> smaller vendors (TMT,VP) follow it, and it also has following in the
> open source community.[/color]

So, you still can't share code with embedded systems. I can and *have*
done so for *real* work on *complex* applications.
[color=blue][color=green][color=darkred]
> >> I used three C/C++ compilers. VC++, Keile C51 and gcc on FreeBSD.
> >> All codebases were pretty uncompilable on the compilers they were
> >> not written for, because of extensions, libraries etc.[/color]
> >
> > Both VC++ and gcc can compile ANSI standard C (I don't know Keile
> > C51) so as long as you keep your implementation specific code
> > isolated[/color]
>
> Sure, but that was not what I said. I said the compilers can't compile
> an average program from the other.[/color]

Berkeley DB (the one used to drive the Amazon web site, amongst others)
is built using gcc for Linux and VC++ for Windows. Maybe that is a well
written program rather than an average program.

The application I work on, several hundred thousand lines of code, used
to be built for Windows using VC++, for Linux using gcc and for HPUX,
SCO, AIX and Solaris using the standard compilers from the relevant OSs.
This is using the *same* source files in all cases. It is also software
that my company earns millions from annually.

I changed this to standardising on gcc because I wanted to and gcc is
available for all the targets we want to support.
[color=blue][color=green]
> > (sometime I always try to do) then the bulk of your code will
> > compile and run correctly on both.[/color]
>
> And be fairly trivial.[/color]

Do you think an applications several hundred thousand lines long is
trivial? Or Berkeley DB which is used to power a lot of major web sites?
Or software for performing real time analysis of video data which I
debugged by running natively on a workstation before running
*unchanged* in an embedded system?
[color=blue][color=green][color=darkred]
> >> IOW I don't see a fundamental difference. True, the number of
> >> language variants, and the average number of extensions etc are a
> >> bit less in the C case, but that is more the language popularity.[/color]
> >
> > One major difference, almost all C compilers produced for a long
> > time have been able to compile ANSI standard C, I don't think the
> > same can be said about Pascal.[/color]
>
> No, and probably never will. I don't dispute that. I'm just saying it
> is overrated.[/color]

Well, standard C is very useful for us C developers for writing *major*
applications.

If, on the other hand, I wand to quickly knock up a toy GUI applications
I'll reach for VC++, Delphi or similar and sod portability.
[color=blue][color=green][color=darkred]
> >> With both languages carefully crafted codebases are somewhat
> >> portable, but in both cases the subset is too limiting.[/color]
> >
> > My experience was that *no* Pascal module compile on any compiler
> > other than the one it was written on because it would fail as soon
> > as you reached the line indicating it was a module rather than a
> > program or as soon as it referenced any other module, whichever came
> > first.[/color]
>
> Well, that is not my experience. The borland versions (generations is
> a better world) are backward compatible till 1985, and ansi pascal is
> pretty close to compability with even J&W pascal.[/color]

I know that Borland Pascal is vastly different from any other Pascal
I've used (I forgot to mention having used Turbo Pascal 5.5 and Borland
Pascal).

So you have one manufacturer providing backwards compatibility with it's
own products, other trying to hit this moving target and some compilers
that aren't quite ansi compliant. Whereas for C we have almost every
compiler written since the early 90s supporting standard C.
[color=blue][color=green][color=darkred]
> >> (ansi C+posix is already
> >> a bit better, but that is more than a mere language standard, and
> >> it still sucks on Windows)[/color]
> >
> > Windows has Posix compatibility layers, depending on what you want.[/color]
>
> Sure. But that is not ansi isn't it?[/color]

So you keep your hooks to it isolated in one module. Then you have a few
percent of your code to rewrite and the bulk of it standard. I know, I
*do* this on *large* projects.
[color=blue][color=green]
> > also has GTK available if you want a common graphics handling code
> > between Windows and Unix.[/color]
>
> (GTK on windows sucks, but)
>
> GTK is also not exclusive to C. Actually the RAD of the pascal
> compiler I use uses GTK on Unix platforms (but native winapi on win32)
>
> Delphi does something similar, but uses QT.[/color]

I didn't say that you could not interface to cross-platform graphics
libraries from Pascal. I was pointing out that the libraries not being
part of C was not a major problem.
[color=blue][color=green][color=darkred]
> >> > If there are *now* ANSI Pascal compilers for most targets and a
> >> > way to easily mix Delphi and ANSI Pascal then things have
> >> > changed.
> >> Delphi and Ansi Pascal are not really mixable, except on the most
> >> minimal level. Pretty much like VC++ and Keile C51.[/color]
> >
> > As I say, I don't know Kiele, but it is possible to have code that
> > can be compiled by both VC++ and gcc. Look at Berkeley DB for one
> > example.[/color]
>
> I can also craft Pascal code accepted by (nearly?) every compiler, so
> what's the difference?
>
> (well, there actually is. The string handling of that code
> will be clumsy. char ident[x] based like C, and that is not how you
> use strings usually under Pascal)[/color]

So you have to use a sub-set of Pascal where as I have the whole of C
available to me.

I also have implementation specific extensions for the small percentage
of the code (normally under 10% on the applications I've dealt with)
that requires it.
--
Mark Gordon

[Mark Gordon]

Re: Future reuse of code

On Mon, 18 Aug 2003 10:52:08 -0400
Joe Zitzelberger <joe_zitzelberg er@nospam.com> wrote:
[color=blue]
> In article <20030812135022 .586618b0.spamt rap@flash-gordon.me.uk>,
> Mark Gordon <spamtrap@fla sh-gordon.me.uk> wrote:
>[color=green]
> > On Tue, 12 Aug 2003 07:57:18 -0400
> > Joe Zitzelberger <joe_zitzelberg er@nospam.com> wrote:
> >[color=darkred]
> > > In article <ff82ae1b.03081 20009.43157fcf@ posting.google. com>,
> > > ruse@webmail.co .za (goose) wrote:
> > >
> > > > and yet creating a std C program would not only get you that, it
> > > > would also get you a fairly snappy application *and* leave you
> > > > open in the future to be able to support those people who have
> > > > machines that are not capable of running java (certain designer
> > > > palmtop-types) to *also* interface with the campus machines.
> > > >
> > > > java doesn't *buy* you anything extra in terms of portability.
> > > > The only relatively *portable* way I can think of is when
> > > > writing applets for web-pages (note: /relatively/). as long as
> > > > the browser has a java runtime environment, of course.
> > > >
> > > > Java does have its advantages. Portability isn't one of them.
> > >
> > > ???Huh???
> > >
> > > Which sort of Java isn't portable? I get binary compatibility on
> > > all desktop/server/enterprise machines and many embedded as well.
> > > If that fails (it never has) I get source level compatibilily (the
> > > compiler is written in java after all...) across all the
> > > platforms.
> > >
> > > Now it might not make any sense for me to try and open a dialog
> > > box on a stoplight, and the stoplight manufacturer might well
> > > leave those libraries out, but that hardly makes it non-portable.[/color]
> >
> > What if the JVM has not been ported to the processor you are using?
> > Can you find a JVM for any of the following processors?
> >
> > Z80
> > 6502
> > 8051
> > TMS320Cxx
> >
> > just to name 4 families of processor off the top of my head all of
> > which are used in *current* projects.
> >
> > Even if you ported the JVM it would run like a snail on
> > tranquilisers.[/color]
>
> I used the Pascal byte code system, precursor and work-alike to modern
> Java, on the 6502 and Z80. And yes, it did run like a snail on
> tranquilisers. For that matter, so did highly tuned assembler and
> compiled C.
>
> Anyone who wants to license a reference implementation from Sun can do
> so for $150,000, IIRC, and write a very think hardware layer to get
> Java on thier chip/os.[/color]

That is a lot of money to spend compared to the cost of a C
implementation and it probably still won't help you for all the target
I mentioned.
[color=blue]
> There are also clean room clones available...[/color]

Not for all the targets I mentioned.
[color=blue][color=green]
> > Also we had to upgrade from SCO 5.0.5 to SCO 5.0.6, something I'm
> > told was painful, on several customer sites in order to be able to
> > run a specific Java application. Java 1.4 is not available for
> > earlier version of SCO and was not available at that time for AIX,
> > which another of our customers uses.[/color]
>
> I've not played with SCO for a while (1997 to be exact), but a minor
> release ought not prevent you from running Java 1.4? What happened
> when you installed it on 5.0.5?[/color]

I can't remember the specifics, but the JVM does not run.
[color=blue][color=green][color=darkred]
> > > All of this talks of applications, not applets which were a cute,
> > > but useless toy.[/color]
> >
> > As have the people talking about processors where the JVM is not
> > available.[/color]
>
> A brief search of Google shows at least one JVM product targeted at
> the 6502, specifically C64, from mts.com. And a JIT compiler/runtime
> targeted at Z80/6502 from Stanford. Also a hardware boost for th
> 6502/65816 family from Fawcett.[/color]

So you found two of the 4 targets I mentioned. I found one that targets
the 8051. However, I can't see one for the TMS320C25 and I did look.
[color=blue]
> That is the first results page. I'm not sure what any of the statuses
> are.[/color]

Taking 20K for the JVM when you have a limited memory space could be a
problem. It would not run on the systems where we only had 8K of ROM and
2K of RAM.
[color=blue][color=green][color=darkred]
> > > Have you ever actually tried porting an application to another
> > > hardware/os using std C? It is not just a recompile, there are
> > > plenty of issues the original programmers must have planned for --
> > > and they usually don't.[/color]
> >
> > One program I wrote in C for an embedded system was debugged by me
> > on a Silocon Graphics workstation by running the code natively (not
> > in an emulator or simulator). All I had to do was replace the two
> > functions that talked to the hardware with one function to read test
> > data and another to interface to a graphics library and display the
> > results. The debugged code then ran perfectly on the embedded system
> > without any further changes.
> >
> > Some companies actually hold code reviews to ensure that code is
> > well written, and obstreperous abstrads like be *do* reject code and
> > insist on it being rewritten if the job has not been done properly.[/color]
>
> I think that is a great approach, but I also think it is a rarity to
> have such reviews held.[/color]

Real reviews are mandated on projects for the military and for safety
critical projects.
[color=blue]
> In my experience, "portabilit y" usually means
> running on all versions of Windows, or, at a streach, all versions of
> Windows and some Linux.[/color]

As I've posted else where, my experience includes debugging and running
code natively on a Silicon Graphics Workstation then running it
*unchanged* on an embedded system. There was about 20 lines of C and 40
lines of assembler for the interfacing on the embedded system and a few
thousand lines of C to do the real work. The embedded processor was a
TMS320C25 which has a "byte" size of 16 bits.
[color=blue]
> Something as trivial as endianess (because
> the whole world really runs on Intel, doesn't it) is almost
> universally not considered.[/color]

The application I am currently working on is several hundred thousand
lines of code and it runs on both big and little endian machines and
both Windows and a variety of Unix derivatives.

For the binary files the original author just chose one endianness and
wrote some code to explicitly read the files as bytewise as that
endianness.
--
Mark Gordon