Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Decided to start learnig C

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #31
    don't rule out Turbo Pascal for vintage only programming. Loads of good learning materials for it. As well as Turbo C++. And if you weren't aware, not to insult your intelligence, any C++ compiler can gobble strait C code. But it may need it's specific syntactical rules obeyed.
    Last edited by tipc; November 8, 2020, 06:12 AM.

    Comment


      #32
      Originally posted by ziloo View Post
      Would you please explain what "mission-critical" means as far as
      programming is concerned?

      ziloo
      In its simplest, if the program crashes, people die (or the wrong people die if its a missile control I suppose), though it covers any application or system that if it fails it brings down the whole operation.

      So running an airliner on windows 95 would be interesting every time the BSOD came up.

      I remember reading about a brand new plane that needed a full throttle test against the brakes before delivery, only the software was too clever and refused to allow full throttle with the brakes on. So they applied an override to that function and engaged full throttle, however the software then had a second loop that assumed that with full throttle applied, the brakes should not be engaged and released them. The brand new plane then rammed into the adjacent building.
      Mission Failed !

      At work we use a CUTLASS control scheme to run the reactor and its feed & steam systems. Though in this case, failure of the computer system would lead to a reactor trip rather than a plane falling out of the sky. We do have a second computer system running the shutdown cooling sequence but even thats backed up by a redundant relay logic sequenced cooling system.
      Last edited by Gary C; November 8, 2020, 06:33 AM.
      Current fleet
      TRS80 Model 4 - BBC B - Tatung Einstein - PCW9512 - PET 3032 - C64 - ZX81 - Spectrum 48K - Amiga A500 - Apple II europlus - Apple iMAC G3. Sharp MZ-80K. - IBM 5160 XT - Multibus 286/10 - Micro PDP 11/73 - Rainbow PC100A - MicroVax II - MicroVAX 3100, 3300, VAX 4000 VLC & 4000 Model 96 - AlphaStation 225 Apricot PC - Apple Performa 6200 - Apple Mac IIcx - Osborne 1 - ACT Sirius 1

      Comment


        #33
        what about banking? Is that considered 'mission critical' ? I mean, really hate putting everything in terms of money. it's just, well, so many things depend on it. Know what I min?

        Comment


          #34
          I suppose it does. If they had a system that coordinated all the activities and it stopped the business then yes it would be mission critical.

          I believe all trading was/is? done using the GPS clocks to order trades and account prices and I believe there was a bit of a worry that the GPS had become mission critical for all world trading.

          Not sure if anything has changed, so a debris storm in their orbit would be bad news.
          Current fleet
          TRS80 Model 4 - BBC B - Tatung Einstein - PCW9512 - PET 3032 - C64 - ZX81 - Spectrum 48K - Amiga A500 - Apple II europlus - Apple iMAC G3. Sharp MZ-80K. - IBM 5160 XT - Multibus 286/10 - Micro PDP 11/73 - Rainbow PC100A - MicroVax II - MicroVAX 3100, 3300, VAX 4000 VLC & 4000 Model 96 - AlphaStation 225 Apricot PC - Apple Performa 6200 - Apple Mac IIcx - Osborne 1 - ACT Sirius 1

          Comment


            #35
            https://en.wikipedia.org/wiki/Mission_critical

            Dave

            Comment


              #36
              Banking was one of the earliest adoption of Tandem (remember them?) Non-stopô fault-tolerant mainframes. Still have my copy of Jim Gray's 1985 paper. It still makes interesting reading.
              Reach me: vcfblackhole _at_ protonmail dot com.

              Comment


                #37
                Originally posted by ibmapc View Post
                Someone mentioned that I wouldn't learn much C from seven classes. I think he misunderstood. It's not seven classes. It's SEVEN COURSES. Each course has a bunch of lectures and tests with a Final exam in each course.
                My basic point it this. At the end of the 7 courses, you will ideally have a solid introduction to the C syntax, its primitive data types, control structures, and memory model.

                All of this is very nice.

                But that doesn't mean you'll be able to program a computer. You might be able to understand and read code. (And don't take this personal, I don't mean YOU you, or anything like that, I'm talking in general.)

                Computer programming is beyond syntax, far beyond syntax.

                And, bluntly, you have to apply it, to problems that you care about, that interest you in order for it to stick.

                I look back at my father, who lamented the limitations of variable names in BASIC. He used the variable A, then the variable AA, finally the variable AAA and ran in to trouble, because the early BASICs tended to not discriminate beyond the first 2 characters.

                Now, anyone of experience would decry that what he wanted to do was Wrong. That he was coding the Wrong Way, and had unreasonable expectations.

                His code was awful, but that doesn't mean it was the Wrong Way. As Perl community likes to embrace as a first class concept "There's more than one way to do it". And, IMHO, end user programming should be encouraged. In time, if he stuck with it, wrote more programs, used them for any length of time, I'm sure my Dad would have learned that naming all of your variable A, AA, AAA, B, BB, BBB, would probably end up being a bad idea. But the best way to learn that is by understand what's wrong with it, rather than just parroting some rote principal you heard somewhere. It's one of my quibbles with the whole "Best Practices". Many embrace them without understanding why. And if they did understand, they wouldn't necessarily need lists of Best Practices to follow. And, IMHO, they should understand.

                As an anecdote, I was talking to a lady who had written a quite large data processing system, all in a BASIC that supported only 2 letter variable names. She was quite proud that Z9 was used as the global error code in her programs. That was a standard of consistency for her system. No doubt there were others that made best use of the limited variable naming space. Things we obviously take for granted.

                Programming is a craft to be practiced. Your courses will tell you about the saw, the hammer, the drill, etc. of the C world. But they won't make you a carpenter. Experience is the only way to get that. Which is why it's important to write code. Writer early, write often, mess things up, "do it Wrong". Results over process.

                Which is also why you need to code things the interest you. With my Dad he was either doing engineeering calcs or financial/stock studies. Taking formulas and such from books and trying to apply them. I knew one guy who leased a VAX 11/750 (which was larger than the VAX we had at the office) to do commodities tradiing analysis. He did it all in BASIC, I never saw his code. He was an engineer. But a number of "quality" standards, I imagine his code was "bad", but it gave him the results he wanted, and thats all that mattered.

                But I will tell you he dropped it like a hot potato for a PC running Lotus.

                So, to learn C, you need to apply C. Start with a blank file, start typing in code, and bumbling your way through things until stuff works for you.

                While software is changeable, code has momentum. Early decisions can affect the lifetime of a project. Which is why early on it's important to throw stuff away wholesale and start again, so as to not bring mistakes with you. But don't let that scare you from doing whatever you think will work. You will know when something becomes a problem. Because it then becomes YOUR problem. And those are the best lessons.

                I'm a homespun organic coder. Outside of fundamental FORTRAN syntax, and, most importantly, I/O, I can honestly say a class has never taught me much of anything. It's all been book learning in the trenches with no fear of applying stuff and making it work. I tried to learn FORTRAN on my own, we had a copy for the TRS-80, but I couldn't figure I/O out. It was talking I/O channels, and files, and what not, and I just wanted "Hello world" and "Guess the number". Couldn't figure that out when what few books I had were talking about tape drives.

                I learned BASIC, then started writing BASIC in FORTRAN, FORTRAN in Pascal, Pascal in C, overlaying my knowledge of the old ways on to the new ways.

                So, programming is a craft, the more you do, the better you get. Approach it without fear, you can't hurt anything.

                Comment


                  #38
                  I am all in favour of you learning a new language.

                  I was an assembler, BASIC and PASCAL coder and then got into ADA. At university we had to learn FORTRAN as part of the course.

                  When the Amiga A1000 came out - that was the point at which I had to start learning 'C'.

                  Now, I write most of my 'home spun' code in 'C'. Most machines have a 'C' compiler of one form or another available.

                  After you have done your courses and played with C a bit, I would urge you to read the book "C traps and pitfalls" by Andrew Koenig. This is an excellent book, and shows you how easy it is to write valid code that will get you into trouble.

                  Most modern compilers will detect some of these issues - but only if you switch the appropriate warnings and errors on though...

                  My motto is "A C compiler warning is a run-time error waiting to happen"...

                  Dave

                  Comment


                    #39
                    C is my native language. I recommend it heartily.

                    Comment


                      #40
                      An occasional topic on the Usenet C language forum was Dennis Ritchie posting a snippet of code with the notation:

                      "What does this do?"

                      Occasionally, the answer would be "we don't know". ANSI cleared some of those up. The point is that C was designed as a "quick and dirty" language and not one that was lexically unambiguous.

                      Lexically, C is a minefield. Leave out a semicolon or insert one where it doesn't belong and you've got trouble. Substitute a comma and dreadful things can happen. That's one reason to turn on all of the warning levels when you write code. If it warns you of something, it's best to look at it carefully, since locating the issue in running code can be a nightmare.

                      Also, something not mentioned is "coding standards". Have some, so that code you write 30 years from now is still recognizable as yours and readable. I use as my own, the CDC CPD coding standards of the 1970s, mutatis mutandi. Comments are critical. Say what you're going to do, say what you're doing and then say what you've done. The thousands of lines of uncommented code in Linux drives me nuts.

                      I'm not a fan of artificially strict standards, I think that Microsoft's "hungarian" style guide is a disaster.
                      Reach me: vcfblackhole _at_ protonmail dot com.

                      Comment


                        #41
                        Originally posted by whartung View Post
                        But the best way to learn that is by understand what's wrong with it, rather than just parroting some rote principal you heard somewhere. It's one of my quibbles with the whole "Best Practices". Many embrace them without understanding why. And if they did understand, they wouldn't necessarily need lists of Best Practices to follow. And, IMHO, they should understand.
                        This cannot be reiterated enough. I wish we could drill this into the heads of every instructor and manager in the world.
                        Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
                        Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
                        "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

                        Comment


                          #42
                          I keep reading in this thread a lot of suggestions to the OP that require hours, days or even months of practicing coding.
                          The OP didn't indicate if this is a hobby or if he is trying to break into a job that requires programming.
                          Most people don't have the spare time required to become a proficient programmer unless it's their full time job.

                          Personally, at my age it's just a hobby. Maybe spending time learning how to create a device driver or modifying boot code. Nothing that required hundreds or thousands of lines of code.

                          Comment


                            #43
                            Some of us have spent the better part of our lives coding. In retrospect, that's pretty sad, isn't it?

                            Why oh why didn't I go for fast cars, snazzy clothes loose women and a generally debauched lifestyle instead?
                            Reach me: vcfblackhole _at_ protonmail dot com.

                            Comment


                              #44
                              Originally posted by Chuckster_in_Jax View Post
                              I keep reading in this thread a lot of suggestions to the OP that require hours, days or even months of practicing coding.
                              The OP didn't indicate if this is a hobby or if he is trying to break into a job that requires programming.
                              I mean, any time you want to get into anything, it's going to take time and effort to become good at it. Whether he wants to invest the time is his own decision, but his question was about what would be a good path forward in general, not about what would be the quickest and easiest way to get to a certain specific end goal.
                              Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
                              Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
                              "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

                              Comment


                                #45
                                Originally posted by Chuck(G) View Post
                                Some of us have spent the better part of our lives coding. In retrospect, that's pretty sad, isn't it?

                                Why oh why didn't I go for fast cars, snazzy clothes loose women and a generally debauched lifestyle instead?
                                I managed the fast cars bit, but failed on the loose clothes and snazzy women

                                I like the way C can overwrite the program if you exceed the bounds of a variable. Leads to all sorts of unexpected events.
                                Current fleet
                                TRS80 Model 4 - BBC B - Tatung Einstein - PCW9512 - PET 3032 - C64 - ZX81 - Spectrum 48K - Amiga A500 - Apple II europlus - Apple iMAC G3. Sharp MZ-80K. - IBM 5160 XT - Multibus 286/10 - Micro PDP 11/73 - Rainbow PC100A - MicroVax II - MicroVAX 3100, 3300, VAX 4000 VLC & 4000 Model 96 - AlphaStation 225 Apricot PC - Apple Performa 6200 - Apple Mac IIcx - Osborne 1 - ACT Sirius 1

                                Comment

                                Working...
                                X