OSDev.org

Shrek wrote:
For all ( bussiness ) practical purposes , programming in assembly language does not help at all

Not true at all my friend.

assembly language is basicly the byte codes which are executed by the processor, but in a more understandable form than just 1s and 0s.

when it comes to phoneline businesses, the control over the speed a program is executed is NECESSITY. as the time it takes for the program to take the audio from one end and throw it out of the other, the company CANNOT charge for that time. so if it takes 1 second to send the word "hello" to the recipient of the call, that's half of the company's profit down the drain. whereas if they could do it in 20ms then thats only 2% of the company's profit down the drain.

although despite this, i do agree with you when it comes to GUI's etc. where HLLs are fast enough to display something without glitches occurring onscreen, assembly is not a necessity. but if you want it to work the same on slower CPUs then assembly would be the way to go.

Cheers,
James.

Troy Martin wrote:Jack: The intention was to say that I find it awesome that UbarDPS has the stones to both defend his opinion and keep it professional at the brink of flaming (if we had intolerably unfriendly/flaming members in this debate.) I know being a senior member or mod isn't anything special.

Ubar: Welcome to the forums, I don't mean to intentionally offend people if I offended you.

Nah, you didn't.

A healthy debate is fine; and, it will help the novices see all points of view and make a more educated decision, themselves!

xDDunce wrote:but if you want it to work the same on slower CPUs then assembly would be the way to go.

Cheers,
James.

That is why I have a spare P2 266 sitting here for testing

I used to have an 8088 and running code on it sometimes was like single stepping it through a debugger (cause the computer was so much slower than the one I used for development), Lol.

I'm looking for someone with an embedded 186, a VGA card, and a 1.44MB floppy drive (either one I can buy or one I can send a floppy image to )

From the voice of bitter experience:

Don't harp on about how your OS is the next big thing
This applies especially if it isn't. It's very easy to get overly enthusiastic about 6-12 months work on a kernel and want to show the world. If it's that great people will notice it on these forums and publicize it for you!

Don't keep running with a tutorial kernel
bkerndev is great - it gets you moving and shows you how to do the basics and allows you to make things happen straight away. Finished playing with it? Now do something different! If you want an example of how to waste endless months patching a tutorial OS which is not designed to be extended, see ScorchOS 0.0.7 (along with subsequent patched version!)

Be careful about releases
Will your kernel stand up to scrutiny? If the answer is "no" don't released or you'll be flamed to bits. This sounds horrible, but the fear of your hard work being ripped to shreds should be adequate motivation to produce something half-decent before you release

Do your homework
Not only does knowing the theory come in REALLY handy when it comes to coding your kernel, it also means that if someone comes at you with a question about your project, kernel theory or compilers then you will be more helpful to them.

Don't make this your first project
Not only will you probably make all the above mistakes but your likelihood of success is minimal (many FOSS project managers have gone through several before finding a particularly good one). It'll probably take a few kernels before you produce something worth extending (in varying languages)

Learn the lingo
If you know English you'll find these forums a lot more helpful, and if you know your programming language (and associated compilers and assemblers) inside out then you will find your time much MUCH easier.

I disagree with needing to have a brilliant knowledge about Maths to get involved with Computer Science - you just need to be able to think logically and understand the theory (I'm testament to that fact in that I'm study a degree in the subject later this year without an A Level Maths). Binary and Hex knowledge is handy, but nothing you can't find out on the net

Adhere to those rules though and you won't make the mistakes I did! (On a side note, I'm now working on creating a kernel in FreeBASIC using the barebones tutorial as a starting point. I'll be interested to see where this takes me...! )

General OS rules (and some general rules):
Don't Copy N' Paste: Learn from the code snips, and rewrite it. (General Programming Rule)
Start off with a known good kernel: The BareBones tutorials are great.
Study Existing OSes: You don't care at all, when you read books describing the Windows kernel, or looking at Linux version 0.01 source code. Just study.
Don't be fancy: This defeats the purpose of your program/OS. (General Programming Rule)

imate900 wrote:Start off with a known good kernel: The BareBones tutorials are great.

Extension:

Take small, retraceable steps. Check if they work before moving on. Check in each step in your version control software, so you can come back later to check which commit broke something you didn't realize was broken until later.

(Had to do this recently at the office - several things broke between a 18-month-old version and a 2-month-old version of the software but went undetected at that time. (Yay for non-existing tests...) In the end I actually tried each changeset between the two versions, to hunt down the bug. Turned out there were six of them in total. Without being able to retrace the changes being made, I'd've been screwed, royally.)

Solar wrote:Take small, retraceable steps. Check if they work before moving on. Check in each step in your version control software, so you can come back later to check which commit broke something you didn't realize was broken until later.

(Had to do this recently at the office - several things broke between a 18-month-old version and a 2-month-old version of the software but went undetected at that time. (Yay for non-existing tests...) In the end I actually tried each changeset between the two versions, to hunt down the bug. Turned out there were six of them in total. Without being able to retrace the changes being made, I'd've been screwed, royally.)

Amen. Revision control will save you someday.

It can also make collaborating easier. I work as the "tools guy" for a few sysadmins, because many sysadmins are too stressed and overworked to get around to all the tools they want to make (so that they can be less stressed and overworked, how ironic). Every so often one of them will clone the code and add a feature. Without revision control, it would be difficult to integrate their changes, since I make edits on a daily basis.

I'm very new to operating system development and ASM, but I've been programming end-user applications for a long time. So I will share a bit of what I've learned and my advice to the newcomer looking to make something serious out of programming.

To begin with, before you ever write a single line of code, you need to know the basic terminology of the computing world. If you don't know that 0x14 = 10100 = 20, or if the terms "API", "native" and "managed" sound foreign to you, you're not ready to start programming. Go learn this terminology and the basics of how computers, operating systems and programming works. Otherwise, you will be terribly confused when you read a tutorial or book. Many people want to jump into writing commercial software when they can do nothing more than browse the web and a play a video game. That's a BAD footing to get started on. You need to know what the point of programming is before you try to do it.

So now you're ready to start your quest to becoming a famous, super-duper Matrix hacker! Well, no... You have to be R-E-A-L-I-S-T-I-C. You're NOT poised to write the next World of Warcraft, Windows/MacOS/Linux, or even anything another human being will want to use. This is not going to be a walk in the park. You have to realize how incredibly time consuming, challenging and tedious this is. Sure, writing cool software is loads of fun; but LEARNING how to program in the first place is particulary dull and frustrating. DON'T put the cart in front of the horse. This cannot be stressed enough. If you think I'm just being negative, then you're in for a heartbreaking surprise, trust me...

So where do you start? Well, start with the small, (deceptively) 'simple' and portable language we know as good ol' C. Mind you, I don't mean it's 'simple' to master and write useful software with; I only mean it has few keywords, a clean syntax and strong standardization. C is ubiquitous in the technological world and can accomplish nearly anything with a good programmer behind it. You have to learn how programming works; inside and out. Embrace the language and stick with it. Here you must learn about the concepts of memory, addresses, pointers, objects and what actually goes on behind the scenes when you compile and run your code. You have to learn how APIs, file systems and the user-realm of your target operating system(s) work. When you finally become comfortable with this, you can move on to something more fun!

By now, we'll assume you haven't quit and want to do something serious with this. C has a tendency to wipe out those who are in it just for show and build-up those who are truly willing to be programmers. Now you're ready to move into a high-level language and try to write some software someone will want to use (and of course, you can stick with C too, or use both together!). I strongly recommend this next language be either C# or Java, but preferably C# (*flame shields on*). But DON'T permanently tether yourself and your work to Windows and the MS implementation (*flame shields off*). Be sure to get involved with Mono, dotGNU and other free/open-source implementations. Contribute to open-source projects and learn from the masters. Learn how to interop with native libraries, write networking code, develop your own GUI/controls and make solid object-oriented designs. This alone is not enough; learn how the .NET CLR and Java JRE internals work and how they managed memory and tasks. That knowledge will be invaluable to you whether you stick with high-level GUI programming or try to implement your own virtual or physical systems. By the time you get here, you should have well defined dreams and a clear direction; you should know exactly what you want to do with this and accomplish. P-L-A-N ahead and make friends with like-minded people who you can work and learn with. Buy books, videos, take classes and do whatever it takes to prepare yourself for your dream. Create a team, make a design outline and work together to pursue it. Again, don't put the cart before the horse!

Some other tips for the absolute beginner:

1) Do NOT copy code from tutorials that you don't understand. You are cheating yourself badly and WILL regret it.
2) When you ask a question, NEVER ask someone to give you code (or even more noobishly "plz give me codes", lol).
3) Stay AWAY from BASIC and Visual BASIC (aka VB). YUCK! It's nothing but a verbose and ugly hindrance which will slow you down and hold you back.
4) NEVER start a project without a clear goal and design plan. You will waste hundreds of hours and your team members will probably quit on you.
5) Never "move on" from something you don't fully understand or skip over mysterious bugs. That always comes back to bite you in the ...

ATC wrote:3) Stay AWAY from BASIC and Visual BASIC (aka VB). YUCK! It's nothing but a verbose and ugly hindrance which will slow you down and hold you back.

[Summons BASIC-demon Combustrotus from his mystical realm]

*casts the curse of polymorph and turns ATC into a green parrot*

Seriously, the majority of people are idiots that repeat another about how bad BASIC is, and the arguments Dijkstra once made about GW-basic do not hold for modern versions. I have never seen anybody who came with an argument that wasn't either targeting the user or could also be applied to either C or Java.

In other words:

Oh well, I hate it, and plenty of other people do too. The problem isn't anything physical (it compiles to the same IL or even native in other versions), but the syntax. That's what I hate. It's just slower and clunkier to type "End If" 200,000 times for a decent application than "}", and you have to read through jumbled messes of that. That doesn't jive with me and a great deal of other people, so I stand behind the advice to avoid it unless it honestly appeals to you. Extra typing and room for error is rarely appealing to anyone. For example, C# wouldn't have compiler-gen private fields like this: public int SomeProperty{get; set;} ...if not.

No criticism of you or anyone else who uses it, make no mistake. But implying I'm an 'idiot' because I don't like and advise against BASIC because 'most people[...]' was pretty crude and a bad way to object to someone's statement. Maybe a misinterpretation, and I won't take it to heart. But rest assured, you'll never see me insult anyone here.

ATC wrote:But implying I'm an 'idiot' because I don't like and advise against BASIC because 'most people[...]' was pretty crude and a bad way to object to someone's statement.

Because that's not what you initially said. You claimed that NOBODY should use basic because of YOUR opinion about it. Frankly your logic went like "death to all muslims because they are (all) terrorists". Using arguments of taste as an excuse to terrorize something only costs you.

And frankly, you're still an idiot for even bringing up the issue.

Oh, this?...

7: Please try to behave
No spamming or advertising. No flaming. No obscenities. Don't provoke fights or participate in fights started by others. Windows vs linux and programming language battles have been fought many times and resulted in a draw every single time. After you've written a post, check to see if it's polite, professional and helpful; and if it's not then it'd be wise to rewrite it or delete it instead of sending it. If you feel that a post breaks these rules, do not reply to it. Please use the "report this post" link to alert the moderators.



The thread is "Advice for novice programmers thread", and I gave mine. Take it or leave it. You gave yours, sorta. But have a good day/night (whatever time zone) and best of luck to you on your project(s). Not being sarcastic. Take care.

Regards,

A few random tips I can think of:

• I encountered object-oriented programming a long time ago backwards and in a borky way, and didn't get the best out of it. Having recently learnt Java, I've suddenly got a new appreciation for how elegant and powerful proper object-oriented code can be. If you're using any language which supports OOP, read up on that section of the manual, so you can get the best out of it, because you might be missing out.
• Elegant code that's easy to understand is better than confusing code that runs faster. It just is.
• Run benchmarks to find out where the real-world bottlenecks are before hacking away randomly trying to speed things up, or obsessing over microbenchmarks on code that won't make any difference.
• This isn't very useful but it's a mild curiosity: In C-like languages there's an extra operator you didn't know about -- the boolean cast pseudo-operator, "!!" (read: "bang bang"). It's occasionally applicable in dynamically-typed languages like JavaScript and PHP. One can do:
  x = !!x;
  to cast x to a boolean.
• C-like languages don't have a logical XOR (^^) operator. You might try to do:
  if ((a && !b) || (!a && b));
  but think about how XOR works -- it's an inequality operation. It returns 1 if both bits are different. So the simpler version of ^^ is:
  if (!a != !b);
  The ! is simply a boolean cast. It could be !!, but you can take out a factor of ! from both sides of the inequality.