Forum > General
OS-es, obfuscation and strings
SymbolicFrank:
Operating systems are written in C. Well, long ago, they were written in assembler. But after that, C.
Many people think that's stupid, because, obviously C++ is a better choice. It's newer. It's designed to be a better C. So, it would be better to use that. Right?
Eh, no. C++ requires things like a memory manager and scheduler to be able to function. Or, in other words: an OS. And C++ is very broken.
There are very many courses, seminars and trainings that help you navigate the vast amount of programming pitfalls the average programmer encounters daily. And they are all about C++. Because other programming languages rarely suffer from those problems.
There are many problems with C++. But the main ones are: speed over all, templates, void pointers, no finalizers, no modules and strings.
Speed: If anything that would make programming better and safer takes longer to execute, it is automatically disregarded. Programmers are expected to know in detail how everything works. The compiler isn't going to help you.
Templates: They can redefine everything. So, some random line of code, somewhere in the project, can change what any keyword or variable does. So, you have no idea what your code is going to do in a large project. And this is regarded one of the best features of C++!
Void pointers: There are very many ways in C++ to address things. Like, if you want to change the value of a variable, you can use the variable name and have it dereferenced automatically, you can use an explicit reference, or simply put an asterix in front. There are more, like arrays. And while they all seem to do the same thing, they don't. You have to use the same pattern that was used to declare the variable. Often, the only way to do that is to cast it to a generic ("void") pointer. And that throws away all the type information. The compiler cannot check the correctness.
Finalizers: In Free Pascal, you have try..finally. Which will execute the code after "finally" no matter what (well, unless your app is already killed by the OS). And that's why destructors work. You are assured that they will run. Not so in C++. It's a minefield. Stuff might get freed, depending. Lots of papers have been written about this.
Modules: In C++, all your code is build as a single unit. You can compile parts, if you supply the object file and a header file. And the right versions of all the parts. That's why it is very hard to use any downloaded code. It probably won't work, because there's a discrepancy in one of the hundreds of header files used. Which you cannot fix, because your version is slightly different. And because it evolved from a C pre-processor, all the names are mangled. That's why we have namespaces, instead of modules. And namespaces can be distributed throughout the source code. If there are a hundred people working on a project, they can all be maintaining part of all of those namespaces...
Strings: Or, dynamic arrays in general. This should be the big showstopper. In C and C++, most arrays are unlimited in size, and end when an item has value 0. So, they never know how long an array is. To find out, you have to read all the items until you encounter one that is 0. This is what most malware uses to penetrate, and why C and C++ software is so very buggy.
So, why is C++ used so much, if it is so bad? Well, it was seen as an upgrade to C, the programming language most programmers used at that time, and so it is what most senior programmers have used most of their life. It's what they're familiar with. To them, it is how it should be.
So, why is it that most programming languages use the C syntax, instead of something verbose, like Pascal or Fortran? Two reasons. First, it seems that there are less characters to type in C: "{" instead of "begin", for example. That isn't really true, because you have to specify more meta-data. And you have to provide much more comments, because C and C++ are hard to read and understand.
But, the cryptic nature is seen as a good thing. It makes your job sound much better, if it looks like incomprehensible mumbo-jumbo. Also, getting a job is easy, but to keep it you have to make yourself indispensable. Or, at least, that's a common rhetoric. And the best way to do that, is to make sure nobody understands your code.
This is also reinforced by the need for speed. No matter that the speed of 99% of your code is irrelevant and barely measurable, many (C and C++) programmers feel the need to make sure that every bit of their code is smoking. They don't trust the compiler to get it right, which is probably a good thing because even compilers find C++ really hard to comprehend. Writing your code in a totally incomprehensible way, but which might be a bit faster is seen as mastering your profession.
So, what does this have to do with Free Pascal? Simple. It doesn't have those problems. If you rewrote Linux in it, it would be nearly bullet-proof. But them again, no OSes are written in it, and you don't need to create a free pascal compiler to roll out your tool chain. Because that is written in C and C++.
jamie:
I believe long ago WINDOWS was written in Pascal based language.
lucamar:
--- Quote from: jamie on March 11, 2019, 02:53:27 am ---I believe long ago WINDOWS was written in Pascal based language.
--- End quote ---
Windows? No: MS's Pascal was never that good. But great swaths of the first versions of MacOS? Damn yeah :)
440bx:
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---Eh, no. C++ requires things like a memory manager and scheduler to be able to function. Or, in other words: an OS. And C++ is very broken.
--- End quote ---
No, that simply isn't the case. C++ can be used as a strongly typed C. There is nothing in the language that forces the programmer to use C++ facilities he/she doesn't want.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---There are very many courses, seminars and trainings that help you navigate the vast amount of programming pitfalls the average programmer encounters daily. And they are all about C++. Because other programming languages rarely suffer from those problems.
--- End quote ---
I have to admit you are right there. Both C and C++ are filled with "subtleties" (commonly referred to as "implementation dependent" constructs) that can bite a programmer.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---There are many problems with C++. But the main ones are: speed over all, templates, void pointers, no finalizers, no modules and strings.
--- End quote ---
The lack of modularity is a problem. The rest is a problem because the programmers using it either don't know how to use the features or can't help themselves from showing off.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---Speed: If anything that would make programming better and safer takes longer to execute, it is automatically disregarded. Programmers are expected to know in detail how everything works. The compiler isn't going to help you.
--- End quote ---
The speed problem isn't the compiler's problem, it's a programmer problem, can't fault the language for that but, that said, C/C++ do encourage poor programming (hard to maintain code.)
Programmers should be expected to know in detail how everything works. When I get on an airplane I expect the pilot to know how everything works. Programmers should be held to the same standards as in any other profession: know your stuff. Period. No excuses.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---Templates: They can redefine everything. So, some random line of code, somewhere in the project, can change what any keyword or variable does. So, you have no idea what your code is going to do in a large project. And this is regarded one of the best features of C++!
--- End quote ---
I don't think templates are that great of a feature but, C++ programmers are far from being the only ones addicted to them. They do tend to be misused and abused. That's more a programmer flaw than a language flaw. If someone uses a toothpick to blow their nose, the poor judgment didn't come from the toothpick.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---Void pointers: There are very many ways in C++ to address things. Like, if you want to change the value of a variable, you can use the variable name and have it dereferenced automatically, you can use an explicit reference, or simply put an asterix in front. There are more, like arrays. And while they all seem to do the same thing, they don't. You have to use the same pattern that was used to declare the variable. Often, the only way to do that is to cast it to a generic ("void") pointer. And that throws away all the type information. The compiler cannot check the correctness.
--- End quote ---
void pointers are not a problem. A void pointer is just a way of declaring the variable contains an address. Automatic dereference, you can blame the programmers that are addicted to syntactic sugar for that and, there are quite a few of those.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---Finalizers: In Free Pascal, you have try..finally. Which will execute the code after "finally" no matter what (well, unless your app is already killed by the OS). And that's why destructors work. You are assured that they will run. Not so in C++. It's a minefield. Stuff might get freed, depending. Lots of papers have been written about this.
--- End quote ---
Finalizers didn't exist for decades, yet programmers managed to create software without them.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---Modules: In C++, all your code is build as a single unit. You can compile parts, if you supply the object file and a header file. And the right versions of all the parts. That's why it is very hard to use any downloaded code. It probably won't work, because there's a discrepancy in one of the hundreds of header files used. Which you cannot fix, because your version is slightly different. And because it evolved from a C pre-processor, all the names are mangled. That's why we have namespaces, instead of modules. And namespaces can be distributed throughout the source code. If there are a hundred people working on a project, they can all be maintaining part of all of those namespaces...
--- End quote ---
Modularization has never been one of the best features of C and C++ inherited that from C because it tries hard to be very compatible with C. The name mangling is just a hack to avoid losing parameter information. Not exactly elegant.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---Strings: Or, dynamic arrays in general. This should be the big showstopper. In C and C++, most arrays are unlimited in size, and end when an item has value 0. So, they never know how long an array is. To find out, you have to read all the items until you encounter one that is 0. This is what most malware uses to penetrate, and why C and C++ software is so very buggy.
--- End quote ---
What you state there applies mostly to arrays of characters not to all arrays as your statement implies.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---So, why is C++ used so much, if it is so bad? Well, it was seen as an upgrade to C, the programming language most programmers used at that time, and so it is what most senior programmers have used most of their life. It's what they're familiar with. To them, it is how it should be.
--- End quote ---
One reason is because C++ catches a lot more errors at compile time than a regular C compiler. That is very nice feature of C++ and, it doesn't "assume", if the programmer failed to specify something, C++ will output an error or at the very least a warning.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---So, why is it that most programming languages use the C syntax, instead of something verbose, like Pascal or Fortran? Two reasons. First, it seems that there are less characters to type in C: "{" instead of "begin", for example. That isn't really true, because you have to specify more meta-data. And you have to provide much more comments, because C and C++ are hard to read and understand.
--- End quote ---
I believe you have a valid point there, except for the comments part. C/C++ programmers are notorious for not adequately commenting their code and producing verbal cubism when it comes to naming variables.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---But, the cryptic nature is seen as a good thing. It makes your job sound much better, if it looks like incomprehensible mumbo-jumbo. Also, getting a job is easy, but to keep it you have to make yourself indispensable. Or, at least, that's a common rhetoric. And the best way to do that, is to make sure nobody understands your code.
--- End quote ---
You have a point there.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---This is also reinforced by the need for speed. No matter that the speed of 99% of your code is irrelevant and barely measurable, many (C and C++) programmers feel the need to make sure that every bit of their code is smoking. They don't trust the compiler to get it right, which is probably a good thing because even compilers find C++ really hard to comprehend. Writing your code in a totally incomprehensible way, but which might be a bit faster is seen as mastering your profession.
--- End quote ---
a responsive program that works as it should is usually a pleasure to use, therefore attention to speed isn't that bad. The kind of attention it gets is often where the problem resides. When speed is obtained at the expense of maintainability then it can quickly become a problem and, it's true that too many C/C++ programmers seen to have been bitten by the speed over maintainability bug.
--- Quote from: SymbolicFrank on March 11, 2019, 01:27:43 am ---So, what does this have to do with Free Pascal? Simple. It doesn't have those problems. If you rewrote Linux in it, it would be nearly bullet-proof. But them again, no OSes are written in it, and you don't need to create a free pascal compiler to roll out your tool chain. Because that is written in C and C++.
--- End quote ---
O/S code must be fast. That's one of the very few areas where speed is occasionally more important than simplicity (which implies maintainability.) The compiler has to be able to generate solid optimized code and FPC could definitely be improved in that area.
FPC is good and, with some effort it could probably be used to write an O/S but, there would be a fair number of bumps on the road to getting there.
Thaddy:
--- Quote from: 440bx on March 11, 2019, 07:25:12 am ---FPC is good and, with some effort it could probably be used to write an O/S but, there would be a fair number of bumps on the road to getting there.
--- End quote ---
I agree with almost anything except the above: Pascal is and was widely used to write OS's including of course embedded systems. Those OS's are not as mainstream like they used to, but industrial OS code is still often Pascal code.
I can't see the bumps....I have even seen RTOS systems fully written in Pascal (not object pascal) and FPC supports this and is fast enough. ('fast' is a speed-trap that can go for any high-level language implementation... :D )
A computer scientist will not tie a high-level language with speed at all: such correlation is simply not there -spurious, if you want-. It is the implementation, which is a wholly different thing.
Navigation
[0] Message Index
[#] Next page