Glass Panel Longevity

Roger (K8RI) wrote:
As a side note, you could start with about 37K of source code which is
what the greeters program ran for the EAA. That compiled into about 7
megs due to the DLLs

VB has always been a pig... Hell, even back in the non-Windows days of
just compiled MS-BASIC it sucked... It was hidden from you by the fact
that the executable was small because it didn't contain everything that
got loaded at runtime... You had to have the BASIC runtime loaded also...

The more languages I deal with over the years, the more I appreciate
straight 'C'... It's clean, it's efficient, it's predictable...

john smith wrote:
The recent thread regarding the lack of parts for the Garmin 480 got me
to wondering just how long the G-1000's will "live"?
Steam gauges are forever, but integrated circuits are produced for a
given period, then production is ceased as newer chips come along.
Does Garmin mention anywhere how long they will support their products?
Their earliest GPS handhelds are coming up on 20 years.
We have seen Lowrence discontinue support for some of their products
that are less than 10 years old.

Just like everything else that gets disontinued, either you have to
throw it away or someone starts manufacturing short runs of
discontinued parts. That is not unfeasible, by the way, for a G1000.
The big problem would be overcoming any legal obstacles thrown up by
Garmin.

The thing is, most chips and circuit boards should last for a very long
time, possibly longer than the airplane, and there will be replacement
parts from scavenged airplanes available.

On Mon, 23 Oct 2006 04:10:17 GMT, Grumman-581
wrote:

Roger (K8RI) wrote:
As a side note, you could start with about 37K of source code which is
what the greeters program ran for the EAA. That compiled into about 7
megs due to the DLLs

VB has always been a pig... Hell, even back in the non-Windows days of
just compiled MS-BASIC it sucked... It was hidden from you by the fact
that the executable was small because it didn't contain everything that
got loaded at runtime... You had to have the BASIC runtime loaded also...

The more languages I deal with over the years, the more I appreciate
straight 'C'... It's clean, it's efficient, it's predictable...

And they finally gave us the ability to turn the type checking on.
:-)) Originally it just assumed the programmer knew what they were
doing and let you do it what ever it was. Lordy...pointers with
dynamic memory, dynamic arrays, linked lists, circular linked lists
and bidirectional linked lists. It gave the programmer a good feel
for the two words, new and free. :-)) Oh yah, and memory leaks.

Straight C is what I wrote my first compiler in. I was the only one in
the class that wrote an input scanner using current and next state
arrays. They tell me I was only the third one in the history of the
school to do that. :-)) Every one else used logic statements.
Compiler wasn't bad but network theory almost did me in.


Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

On Mon, 23 Oct 2006 04:04:25 GMT, Grumman-581
wrote:

Morgans wrote:
What is the VB program to which you are talking about?

At that time, it was in-house developed security administration
software... The real work was done in 'C' (i.e. the various daemons,
services, and DLLs, and the gee-whiz user interfaces were in VB... It
allowed us to utilize developers who could paint pretty pictures ...
uhhh ... user interfaces ... but who were not really competent in the
technical matters of communicating with remote machines, much less the
security aspects of each of the different platforms... I gave the VB
developers a nice library interface that made adding a new system pretty
much cookie cutter for them and they put the bells and whistles in it to
make it look fancy for the users...

Basically (no pun intended..ah what the hell...) it was pretty much
the first of the "bloat code" generators which was followed by Delphi
and the other "visual" codes. Delphi was kind of nice to use as it
was pretty much a visual Pascal.

The most difficult thing I found about C was making sure to put in the
internal documentation so you could figure out what you did two weeks
after you wrote it. C has often been referred to as a "write only"
language.:-))

Delphi and Visual C++ are true object oriented languages ... if the
programer knows how to use them that way. Otherwise they end up with
a bunch of source code that compiles into really big programs with a
lot of usless links and DLLs and no, or little useful inherritance.
(every thing declared global) I don't know if VB ever evolved into a
true Object oriented language or not as I've done so little
programming in the past few years. It seems like I remember that it
was pretty much object oriented.

Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

Roger (K8RI) wrote:
And they finally gave us the ability to turn the type checking on.
:-)) Originally it just assumed the programmer knew what they were
doing and let you do it what ever it was. Lordy...pointers with
dynamic memory, dynamic arrays, linked lists, circular linked lists
and bidirectional linked lists. It gave the programmer a good feel
for the two words, new and free. :-)) Oh yah, and memory leaks.

Wow, expecting engineers to do it correctly... Radical concept, eh? grin

With regards to type checking, well, you just ran 'lint' on your code to
give yourself a better feel for it... I liked the level of strictness
with regards to type checking in standard 'C'... I hated what Ada
required us to do... More often than not, things became a system.address
type in Ada for what I was having to do...

You can be object oriented in standard 'C', it just takes the right
frame of mind... While I was working on a NASA contract for the MCC and
SSCC, we utilized this technique. Here's a write-up that I did on it
awhile back describing it:

http://grumman581.googlepages.com/object-oriented-c

We had a lot of different groups each working on different portions of
the entire system and these would be linked at a later date and expected
to work together. Collisions at link time were not acceptable.

On Mon, 23 Oct 2006 22:39:00 GMT, Grumman-581
wrote:

Roger (K8RI) wrote:
And they finally gave us the ability to turn the type checking on.
:-)) Originally it just assumed the programmer knew what they were
doing and let you do it what ever it was. Lordy...pointers with
dynamic memory, dynamic arrays, linked lists, circular linked lists
and bidirectional linked lists. It gave the programmer a good feel
for the two words, new and free. :-)) Oh yah, and memory leaks.

Wow, expecting engineers to do it correctly... Radical concept, eh? grin

Radical huh? :-))

With regards to type checking, well, you just ran 'lint' on your code to

This was before ANSI C and lint.

give yourself a better feel for it... I liked the level of strictness
with regards to type checking in standard 'C'... I hated what Ada

The original C didn't have any type checking. You could add, or
combine anything with anything regardless of type be it an address,
integer, floating point, pointer, array, string, ordinal value, what
ever. It added a new dimension to debugging:-))

Never have worked with Ada.

required us to do... More often than not, things became a system.address
type in Ada for what I was having to do...

You can be object oriented in standard 'C', it just takes the right
frame of mind... While I was working on a NASA contract for the MCC and

"Object Oriented" is really a programming concept although we tend to
think of specific languages such as Delphi and C++ as being Object
Oriented. If the programmer properly organizes the language he is
using he can create the same inheritance and relationships in most
languages although being able to define a variable as local or global
makes it a tad easier. Of course global makes it easier to defeat the
whole concept too.

SSCC, we utilized this technique. Here's a write-up that I did on it
awhile back describing it:

http://grumman581.googlepages.com/object-oriented-c

We had a lot of different groups each working on different portions of
the entire system and these would be linked at a later date and expected
to work together. Collisions at link time were not acceptable.

You mean something like a number of modules/routines using the same
variable name defined locally and then some one assigns it global? Or
assigning a value to an address that some one else uses for something
else.? I don't know how many times I accidentally assigned global or
local wrongly. I haven't done any programming in C or even C++ in a
long time. (I've been retired 10 years now)

Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

Roger (K8RI) wrote:
This was before ANSI C and lint.

I've had more than my share of pre-ANSI compilers... It seems that
nearly every project that I work on, at least one of the machines not
only does not have a C++ compiler for it, it doesn't have one that is
POSIX or ANSI compliant either... As such, you program for the greatest
common denominator -- standard 'C' -- so that you can have a single
piece of source code that compiles across all platforms...

The original C didn't have any type checking. You could add, or
combine anything with anything regardless of type be it an address,
integer, floating point, pointer, array, string, ordinal value, what
ever. It added a new dimension to debugging:-))

But it *built character*... Just look at the quality of developers that
you see these days and it will readily become apparent to you that we
have a *lot* more character than they do...

Never have worked with Ada.

You're not missing much... A language designed my committee -- and it
shows...

"Object Oriented" is really a programming concept although we tend to
think of specific languages such as Delphi and C++ as being Object
Oriented.

Yeah, as I've always said, you can write crap code in *any* language...

If the programmer properly organizes the language he is
using he can create the same inheritance and relationships in most
languages although being able to define a variable as local or global
makes it a tad easier. Of course global makes it easier to defeat the
whole concept too.

Agreed... Allowing the concept of scoping is a quite useful feature in a
language... More often than not though, most code that I've reviewed on
projects believe in basically two levels of scoping -- at the global
level and at the function level... Occasionally, you will see a
developer declare a variable in a local block of code, but it doesn't
seem to happen that often, primarily in some sort of loop counter or
accumulator... From a documentation standpoint though, it looks better
if the variables are defined at the beginning of the functions... Code
should be readable and documentation should be inline so that you can
remember *why* you were doing something a particular way when you have
to come back in a couple of years and modify the code... I like to think
that you should document the code as if you were going to be having it
published in a major publication and subject to peer review... I don't
see that happening with the developers who utilize the MS Visual C++ (or
whatever) type of products... They draw their user interfaces and plug
in the callback actions and about the only comments that you get are
whatever the MS development environment automatically includes in the
code...

You mean something like a number of modules/routines using the same
variable name defined locally and then some one assigns it global? Or
assigning a value to an address that some one else uses for something
else.? I don't know how many times I accidentally assigned global or
local wrongly. I haven't done any programming in C or even C++ in a
long time. (I've been retired 10 years now)

When you are developing a library, you usually have some sort of stub
executable that links in the library for testing during the initial
development... Let's say that you decide to use a variable 'x' in your
library and it needs to be declared by the main module... Let's say that
another library is also expecting a variable 'x'... If the library
routines are not expecting the variable to be modified by another
library routine, there could be issues here... If the first library
instead uses 'AAA_x' and the second library uses 'BBB_x', you've
prevented a collision at link time... Requiring the user of your library
to declare variables is just a core dump waiting to happen though...
It's better style if you have your header file for your library do the
declaring and have it look to see if something is defined before either
declaring the variable or giving a extern reference to the variable...

For example:

--- USER MODULE ---
#define DECLARE_VARS
#include "MYOBJ.h"
#undef DECLARE_VARS
--- USER MODULE ---

--- MYOBJ.h ---
#ifdef DECLARE_VARS
int MYOBJ_x;
int MYOBJ_y;
#else
extern int MYOBJ_x;
extern int MYOBJ_y;
#endif
--- MYOBJ.h ---

On the other hand, if a variable is supposed to be only global to the
modules in your library and not visible to someone linking your module
to their code, you should declare the variable with a storage class of
'static' to minimize the chance that someone could screw something up...

It all boils down to proper programming style... If you want to write
good code in 'C', you can... If you want to write crap code in C++, you
also can...

In article ,
Grumman-581 wrote:

Roger (K8RI) wrote:
This was before ANSI C and lint.

I've had more than my share of pre-ANSI compilers... It seems that
nearly every project that I work on, at least one of the machines not
only does not have a C++ compiler for it, it doesn't have one that is
POSIX or ANSI compliant either... As such, you program for the greatest
common denominator -- standard 'C' -- so that you can have a single
piece of source code that compiles across all platforms...

The original C didn't have any type checking. You could add, or
combine anything with anything regardless of type be it an address,
integer, floating point, pointer, array, string, ordinal value, what
ever. It added a new dimension to debugging:-))

But it *built character*... Just look at the quality of developers that
you see these days and it will readily become apparent to you that we
have a *lot* more character than they do...

Yeah. Most of them don't know which end of a soldering iron to pick up,
and wouldn't know what to do with a logic analyzer if you turned it on for
them and stuck their nose in the instruction book.