OSDev.org

So what is this knowledge that most "programmers" nowadays don't even know or stop to think about?

Mostly what under the hood of the OS they are running their programs on.

It starts with memory (ab)use and goes on to huge code, poor file handling ...
I do understand that memory got bigger, disks got bigger and the CPU got faster, but there is a big difference between being less concerned about performance and having no idea where to start looking for performance improvment.

Some of them write code in a manner that make you think they run on a single user OS

It would be a nice idea to force everybody to relive the days of limited code space & limited cpu power. Say, programming an embedded processor. Nowadays you really have to try before you can get a little performance hit. People just don't care about efficiency... if it's 10x as slow as your solution, it's still 100x faster than what I'd call "slow", so I'm not going to fix it, that kind of attitude...

Also, I'd like to convince most people to do a course of basic computer stuff, where you are left with only assembly language and a very small computer memory, plus the request to make some program work. Boot sector work comes close but not entirely the way.

I start programming at 15 in BASIC for Z80... later in ASM for it...
After pause in 19 I'm begin study FASM for x86... and when buy first comp wrote my first program in few days (under DOS)....
In 20 I start study Delphi... and very grow in it...
~ in 22 start study HTML and JavaScript and CSS...
And in 26 return to ASM but for programming in protected mode... and in march 2003 I begin write my own OS (GreyOS)...
Now I am 27....

Hi Candy
I'm against forcing anyone. But one of my thoughts when I design my OS is to have a notify option after the memory manager does the garbage collecting. I will not force the programmer to leave the place clean, but "notify" him that the OS had to do some cleaning and garbage collecting after he (his program) left.
Something like "process XYZ left xxxMB of unfreed memory. Please call the programmer" when you exit the program. It doesn't force you to do the cleaning in a manner that even if you don't your program will keep on running. But on the other hand, getting a message each time you exit your program is annoying enough to make the programmer fix it and become more aware of the way he use the common resources.

I'm still trying to think what would be considered I/O abuse. And how such abuse could be monitored.

a common I/O abuse that i observe is people enforcing streams read 1 byte at a time (thus exagerating the syscall overhead) or people closing and opening the file everytime they need to access it ...

Kernel or application space?

There are two levels of buffering, one in the kernel I/O functions (read() / write()) and one in the C library (fread() / fwrite()). It's actually rather tricky to get these two buffer levels to not doing any buffering at all...

"File can't be open anymore. You have opened the file xxx times and the key got over used and brooke up . One pice is stuck in the keyhole preventing further opens" ..... mmmm I like the sound of this error message .. LOL

That was application space, using "send" and "recv" or write;flush;write;flush; etc.
"while (c!='\n') getc(file)" has no real implications, but "while (c!='\n') recv(socket,&c,1,0);" may put your CPU at real stress ...

Another common misuse is to poll files instead of select()ing them, continuously taking/releasing semaphores at a far too fine-grained level.

And most those students claim they know C already before i give the programming assignment ... Some even know "if (x=NULL) ..." is broken

You know I'm a standards lawyer - fopen() is ANSI-C, select() isn't...

I wouldna care so much about standards than about what is best suited for the problem to solve - without wasting ressources.

To get back on topic, let's for the sake of the argument make a distinction between programming and developing.



Now, this is sort of the hallmark of programming as oppossed to developing. In this context, a programmer or coder if you like, got a problem (more often - an urge to create a program X that does Y where Y might simply be "being cool") and seldoms think of making the code maintainable and easy for others too read.

For a developer this is essential because it is the one thing that enables other developers (and, granted, programmers/coders) to "stand on the shoulder of giants". This in turn enables you to stand on the shoulder of giants and off we go in a lovely and beautiful spiral of progress.

While the mentality "selecting the best tool for the job" is commendable, standards makes things easier even if they can be sub-optimal.

Take electricity for example. Wouldn't it be nice to never, ever need a converter when you're out travelling? 110V@60Hz versus 230V@50Hz is kind of a moot point these days as peoples need for precise timings demands a higher resolution than a single second.

BTW, cheers Sol, cheers Pype!

Don't feel slammed - I just wanted to point out that standards exist for a reason and they should be embraced rather than everyone reinventing the wheel.

someone feeling guilty for holding a well known rant? ];->

You are right with your arguments. Standards are here for a reason. *chuckle* It's just that they shan't relieve the developer from using /dev/brain.

on the other hand, if I have something following the standard at hands which wastes ressources, I have to look: shall I follow the standard and soothe other developers needs or shall I use a tool which lessens the usage of ressources and works *performant* nevertheless.

Well... being in bad mood and using too short a sentence didn't gain much. Hope this clears my point de vue.

I never use *hacks* which some programmers might find cool. I use a very explicit and well formed coding style (well, for me. Others mileage might vary).

Yep. Sooo unfortunately. select quickly becomes a mandatory things to use when you start network programming in C (as far as i know, "socket" and "gethostbyname" aren't ANSI-C either ). Having it working smoothly with FILE* can quickly become a nightmare.